Captive portal manual logout page address
-
So i cant get this to work. I do get a cookie on the devices but i do not get redirected to the logout page.
My index.php looks like this:
} else if ($_POST['accept'] && $clientip && $cpcfg['auth_method'] == "none") {
captiveportal_logportalauth("unauthenticated",$clientmac,$clientip,"ACCEPT");
portal_allow($clientip, $clientmac, "unauthenticated");} else if (already_connected($clientip, $clientmac)) {
/* display already connected page - offer logout */
portal_reply_page($redirurl, "already_connected",null,$clientmac,$clientip);} else
/* display captive portal page */
portal_reply_page($redirurl, "login",null,$clientmac,$clientip);ob_flush();
?>
Any ideas?
-
I detailed this index.php - by putting the whole file on pastbin.com
File: /usr/local/captiveportal/index.php : http://pastebin.com/scYuKTyw - index.php
Just replace the one you have right now.
Be careful : 2.1.5 only !!
edit have it also working on 2.2 now. -
Thanks for your reply. I see that I missed the part for checking for a cookie (my php skills are kinda low).
I'll try this tommorow on a 2.1.5 box.
If I may ask you another question: where do you put your " cookie destroy" code.
-
….
If I may ask you another question: where do you put your " cookie destroy" code.I don't :) (I stopped doing so).
If you want to destroy it, have a look at the index.php
Look for this line:captiveportal_disconnect_client($_POST['logout_id']);$_POST['logout_id']
will be the $session_id.
Just before that line, if you like, you can destroy your cookie. edit: wrong ! had to put that code higher up - before the 'logged-out-windows' is being send - see line 121-124 in index.php : http://pastebin.com/scYuKTyw
Or do what lsense proposed here : https://forum.pfsense.org/index.php?topic=77143.msg422179#msg422179But, what happens if you don't ?
Ones disconnected, the session Id will be 'non-existent' (its a big random number).
So, it can't be reused to re-disconnect, neither disconnect some one else (remember: you have to have the same IP and same sessions Id to interact with a session from some one else).
Anyway, to access the disconnect function, you have to have a valid session first.As said before: I use a https portal login page - with a real certificate (a valid one, guaranteed by StartSSL) - so sniffing the initial login from some one else isn't an easy thing to do.
Important : if you want to debug this kind of stuff, do not use 'echo' all over the place, use this function:
captiveportal_logportalauth($text1,$text2,$text3, $text4);Have a loot at http://pastebin.com/jDHVaNwf to see examples how t use it.
Just drop some captiveportal_logportalauth($text1,$text2,$text3, $text4); on strategic places to see what is getting reached when.
-
Thanks GertJan, got it working now :)
-
I'll give it a try to 'backport' all this to pfSense 2.2 Release.
I'm pretty sure its possible. -
Got it working on 2.2. Just do the same thing :)
-
Got it working on 2.2. Just do the same thing :)
Yep. You're right. Works for me on 2.2 now.
I'll have to do some checking the next severals days - have 'verbose portal logging' activate to see how it goes. -
Hi there,
I am not able to get it working after days effort. I am not using https CP.
Can anyone please write a step by step guide to make this working.
Thanks
Regards
amitaussie
-
I never tried it without https login.
Like: "why do it the easy way, if the difficult way is available ?" :)
https need valid signed certificates by a know authority, I just followed "PFsense 2.1 MultiCP and https with Windows Radius Guide" (in this forum) and …. it worked - costs me some time and zero € or $ **.I'll test the plain http tomorrow morning (can't test my portal on distance >:( )
**) but you need to have a valid, existing domain name on the internet, which, of course, costs some € or $ a year ......
Btw: Here are my portal stats (all stats are pfSense internals) http://www.test-domaine.fr/munin/brit-hotel-fumel.net/pfsense.brit-hotel-fumel.net/index.html#portalusers
-
I am not using https CP.
It works on http.
Guide is on de previous page.
https://forum.pfsense.org/index.php?topic=77143.msg478165#msg478165 -
I am not using https CP.
It works on http.
Guide is on de previous page.
Thanks for the info :)
-
Think im gonna try the less secure IP/MAC solution.
I use it in a enviroment with BYOD en slot of Androids/IPhone dont lauch there browser but login via the OS. So the cookie is not stored.
-
I use it in a enviroment with BYOD en slot of Androids/IPhone dont lauch there browser but login via the OS. So the cookie is not stored.
"So the cookie is not stored" ??
I tested all this with one device : an iPhone 4S (iOS 8x). I know my iPhone stores the cookie, because I get the logout-page.
This page can pop up if the cookie is found and the cookie info contains a current logged-in session ID.I presume all iDevice (iPhone, iPad, etc) and other smartphones, all PC's, that is, the actual clients on our wifi network) are logging in because a browser pops up …. we rarely explain that at the reception (of our hotel).
I NEVER touch or control devices of our clients (the BYOD owners) - some times I know they have 'static IP's ( well ..... ;D) or 'firewalls that block everything except their 'own' home network (well ...... ;D). -
Well i have tested it on different phones. Soms phones open the browser to login. ATM im running Android 5.0.2 and it opens up a captive portal login from Android it self…nog a browser.
A collegue of mine tested it on his iphone while using the system login and not his browser and had the same problem...no cookie.
So here is a screen from my Android 5.0.2.
Check the icon on the left. If i click on that system message it doesnt load a browser.
Ill make more screens tomorrow.
-
-
Well. Great. You're right.
PC's (tested Windows 7) with a default browsers like IE, Chrome FF or whatever: they will receive the cookie.
The integrated iOS browser used by my iPhone thats pops up when I connect to the wifi portal: It will NOT store the cookie.
Hitting again with the 'real' Safari (the build in App) browser the portal page will let me auth again (I was already authenticated) and this time, the cookie shows up in the (his) cache. I could see it **.
(this is what I was doing all the time, I guess, blaming some cache issue.)
When done that, another visit will show me the logout page - as planned.The 'login' browser isn't the same thing as the App browser ? The login browser doesn't store cookies ?
Anyway: the 'cookie system' isn't perfect for mobile or hand held devices like Androids, iDevices, etc.What now ?
As you already said above: Mixing up MAC/IP and Cookie ?** I changed the cookie set code:
[in /etc/inc/captiveportal.inc - in function captiveportal_reapply_attributes($cpentry, $attributes)]$timeout = 0; if (!empty($config['captiveportal'][$cpzone]['timeout']) && is_numeric($config['captiveportal'][$cpzone]['timeout'])) { $timeout = time() + $config['captiveportal'][$cpzone]['timeout'] * 60; setcookie("cookie_portal", $sessionid, $timeout); } else setcookie("cookie_portal", $sessionid, $timeout);If a hard timeout is set then it's used to set a the cookie expiration time.
http://pastebin.com/jDHVaNwf updated in consequence.
-
Hmm i dont understand the idea behind this… :(
-
Nah in Android i get my login page but its not my browser. When i login it closes right after….so no redirect either.
Im crakcing my head around your new code....but i cant figure out your idea behind setting a timeout in the cookie.
-
The 'login' browser isn't the same thing as the App browser ?
Yes. It's not the same thing. The "browser" (Captive Network Assistant) is a piece of junk…
http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/116041-solution-apple-osx-00.html
https://support.ruckuswireless.com/answers/000002368
