Captive Portal's index.php file
-
I have made some changes to the Index.php file used in the Captive Portal.
I have basically added a few form fields on the captive portal page, these are submitted and the index.php script receives these POST variables, and writes them to a file along with the MAC address, IP address and timestamp. The file is opened, locked, appended, unlocked.
It all works fine, and has done for many many months. What I do notice is that sometimes there are multiple lines in the log file from the same user one after the other, two, three or even four times. Different time stamps seconds apart, but the same user. I originally thought perhaps the user was submitting the captive portal form more than once, but I disable the submit button with javascript once clicked.
Is this people using the back button on their browser and then refreshing, or is there something else that would cause the index.php script to cycle?
Sorry if this is in the wrong section, difficult to choose where to put it!
-
Looking at this, I am pretty sure it is users going through the captive portal, being redirected to the redirect page (company home page), and then clicking the back button assuming it will take them back to their original requested site.
They then go back to the captive portal page, and refresh/submit again, resulting in duplicate entries.
I want to figure out a way to prevent this, and thought of using PHP Sessions?
Setting a session when the form is received and processed in the captive portal index.php script, this session being checked when by the captive portal page that displays. If the session exists, rather than present the captive portal page, it could either present a warning, or do a header redirect to the original request, that way, if a user clicks the back button, they will receive their original requested page before the captive portal kicked in.
The only issue I see with this is that the session will remain active while the browser is open, preventing the captive portal page being displayed again if it needed to be.
Although, perhaps, rather than a header redirect to the original requested page, it could redirect to an internal PHP page which resets the session and then redirects to the original request? umm….
-
Looking at this, I am pretty sure it is users going through the captive portal, being redirected to the redirect page (company home page), and then clicking the back button assuming it will take them back to their original requested site.ion and then redirects to the original request? umm….
That's an easy one: let the user get to the requested page and ditch the company home page redirect.
Yes, I know some bosses are obsessed with the idea that every employee mus vistit the company home page at least once a day. And everyone loves this policiy. And, just for the extremely unlikely case that some subversive deviationist actually dares to dislike this, the browser's start page setting is protected via group policies, Firefox, Chrome, K-Meleon, Opera, Safari, whatever are forbidden (because these can be used to surf the 'net without having viewed the company home page). Daily software updates ensure that even if the user managed to hacks IE's start page setting, it gets corrected back to the company home page. Periodic PC inspections are performed to verify that the company home page policy is not circumvented. –- This might, to some people, sound a bit extreme. Unfortunately, I have experienced this. So let's assume that my "easy solution" is out of the question for the original poster.
Assuming that the company home page is whitelisted in the cqaptive portal (so users can still enjoy it even if they forgot their password (or their user ID, which is in large companies often much more cryptic than any password you can think of), you might consider to display it in an IFRAME just below the captive portal login form. That way, users can still enjoy the view, but it doesn't get into the way of their work.
This assumes that the company home page isn't one of the kinds which are overladed with crappy Flash and DHTML animations, which bring every machine just short of a supercomputer to a grinding halt. or even crashes Firefox. No, wait, Firefox was forbidden technologie...erm...
-
;D
It's a pubs WiFi login system, and the owner wants the redirect to his specials page on his website.
I have used sessions, and have tested it out, and it seems to working fine.
The receiving script sets a session.
The call to the function which creates the CP page checks the session first./*receiving script above here*/ //addition start// $_SESSION{'cppassed'} = 1; //addition end// captiveportal_logportalauth("unauthenticated",$clientmac,$clientip,"ACCEPT"); portal_allow($clientip, $clientmac, "unauthenticated"); }else{ /* display captive portal page */ //Addition start// session_start(); if($_SESSION{'cppassed'} == 1){ $_SESSION{'cppassed'} = 0; if(preg_match("/redirurl=(.*)/", $orig_request, $matches)){ $originalredirurl = urldecode($matches[1]); } if($originalredirurl != ""){ header("Location: " . $originalredirurl); exit; } } //addition end// portal_reply_page($redirurl, "login",null,$clientmac,$clientip); } exit; ?> -
Well, it seems to have cut down on the amount of duplicate entries, but there seems to still be two or three each day, but only single duplicates, not multiple.
-
Well, it seems to have cut down on the amount of duplicate entries, but there seems to still be two or three each day, but only single duplicates, not multiple.
I guess because some users bail out faster than the session data gets written.
As an additional measure you could check your logfile if the last 1000 bytes or so already contain the currrent user's MAC address (with a timestamp not older than a few minutes). As you perform locking on the file, you'll have not trouble with race conditions, I think.