Captive portal manual logout page address
-
Do i have to install any other browser in Apple devices to bypass this CNA feature, like chrome etc.?
Will not help. The only way to avoid this junk is to avoid CP detection altogether.
-
No, no, no… you misunderstood that issue. They will be logged out as soon as they've logged in via the crippled CNA "browser". They need to use their real browser to log in if they want to continue browsing.
When i login via CNA everything works fine. I just use the less secure IP/MAC solution.
-
I just use the less secure IP/MAC solution.
Yeah, so what exactly does this have to do with the manual logout page?
-
No, no, no… you misunderstood that issue. They will be logged out as soon as they've logged in via the crippled CNA "browser". They need to use their real browser to log in if they want to continue browsing.
They won't be logout…they r just not getting the cookie (or am I missing something). So I use the IP/MACso users can use CNA or browser.
-
This entire thread has been discussing how to log out people by using a cookie. So yeah, you can use CNA just fine if you not using logout, just don't get why are you discussing this on a CP manual logout thread…
-
This entire thread has been discussing how to log out people by using a cookie. So yeah, you can use CNA just fine if you not using logout, just don't get why are you discussing this on a CP manual logout thread…
No its not. It been discussed using IP/MAC too at the first page..and this does work with CNA. Im just stating this since the cookie solution is troublesome for phones/tablets.
-
doktornotor, you joined in with the "cookie issue with CNA" which, by the way, destroyed half the fun, not because it was true but because I thought it was working good, or all prove was there that it wasn't ;) CNA f*cked that up.
It was lsense, who told use that he uses cookies https://forum.pfsense.org/index.php?topic=77143.msg421812#msg421812
I wasn't doing so, before. I used a lookup with IP and MAC which I found secure enough because my portal uses https. (But, for some reason, it seems to me that most of us don't)Anyway, who cares :D
Maybe I should write-up a cookie+(MAC/IP) …. but what I realy need it the answer to his first:
https://forum.pfsense.org/index.php?topic=77143.msg478165#msg478165
Last "Btw":
@lsense:modify capture of 1.1.1.1 in ipfw : it gets always redirected, even if authenticated
"Could you detail this please ? What is de ipfw rule ? Injected where ?"
(Ok, I know where, but what ipfw rule ? I'm an iptables man)I'd like to know how to make a short simple easy-to-remember logout URL, like "logme.out" or even "logout" that get redirected to the captive portal web server.
Any ideas ?Byw: It's easy to circumvent the CNA login culprit.
Just connect to the Wifi network.
The CNA pops up.
Shut it down ! (iDevice: hit de home button).
Open the real browser, like Safari or whatever you have on your iDevice.
Login.
The cookie will be there.
Tested and works every time on an iDevice. -
I use a NAT rule: IP of CP port 80 redirect to 8002.
And a DNS record: logout.me with ip of the CP.
I bet Isense redirect 1.1.1.1 to CP IP:800x
-
Hi!
Its working for last more than 24 hours, squid3+transparent proxy+ SSL bump+ squidguard + CP Logout page, no glitches, restarted, everything is working flawless, checked on pcs and mobiles. Everything seems Ok! ;D
Thanks & Regards!
amitaussie
-
Hi! All
I have the same problem
I want to logout manual
Please help me step by step.Thank
-
See the first pagr on this topic.
-
thank you …
-
Last "Btw":
@lsense:modify capture of 1.1.1.1 in ipfw : it gets always redirected, even if authenticated
"Could you detail this please ? What is de ipfw rule ? Injected where ?"
(Ok, I know where, but what ipfw rule ? I'm an iptables man)sorry for the timed out reply, I report it here just for reference.
search for the comment "Authenticated users rules" in /etc/inc/captiveportal.inc and put those two lines in:/* Authenticated users rules. */ $cprules .= "add {$rulenum} fwd 127.0.0.1,{$listenporthttp} tcp from any to 1.1.1.1 in\n"; $rulenum++; $cprules .= "add {$rulenum} pipe tablearg ip from table(1) to any in\n"; $rulenum++; $cprules .= "add {$rulenum} pipe tablearg ip from any to table(2) out\n"; $rulenum++; -
@Gertjan
The cookie solution has another disadvantage. If user uses more than one browser in the same session he could logout only with the original login browser. The other one doesn't know the cookie. For me a IP/MAC solution is secure enough. Spoofing the HTTP REMOTE_ADDR is not that easy. You need a proxy server for this. And what is the risk? The effort is high for what? Log-out another user from your hotel network.Working with IP address has another advantage. I use "daloradius" to manage my radius database. In daloradius is a logout functionality which isn't working with Pfsense. Psense hasn't the api of PoD (Package of Disconnect) nor CoA (Change of Authorization). With IP logout I could extend "index.php" with two parameters IP & MAC. With this I could call the logout window and I would be able to disconnect a user from daloradius.
Do we have to patch pfsense always or is there a plan to replace current logout windows in the official Pfsense version? Who is responsible for captiveportal?
-
Unrelated to this thread, we committed a change to 2.3 this week to switch index.php to a logout page if you reload the portal URL.
https://github.com/pfsense/pfsense/commit/d2ecbddc79a9b67cae52fca6cd3b7bebd758b047
Be sure to read the note on the commit.
-
Here are my modifications that work with cookies:
Please note : I use the https version of the captive portal with a valid (startssl.com certificat) (I don't know if this is important).
Right now, (January 2015) this setup works on one of my pfSense installations (an hotel).
I'm using a nearly clean, original "2.1.5-RELEASE (amd64) built on Mon Aug 25 07:44:45 EDT 2014".edit: these pastebin.org files are locked 'forever' - keep in mind that used to work with 2.1.5 - They might need some re-coding for 2.2.
File: /usr/local/captiveportal/index.php : http://pastebin.com/scYuKTyw - index.php - compare and modify last ~ 15 lines
Basically, this parted gets inserted:} else if ((isset($_COOKIE['cookie_portal']) && already_connected($_COOKIE['cookie_portal']))) /* if we have a valid session, display already connected page - offer logout */ portal_reply_page($redirurl, "already_connected",null,$clientmac,$clientip);File /etc/inc/captiveportal.php :
-
Replace the entire function portal_reply_page(…) with this one : http://pastebin.com/piamkhNB
-
Just above this new function portal_reply_page(...), add this new function already_connected(…) : http://pastebin.com/CFatytZ9
-
Replace the entire function portal_allow(…) with this one : http://pastebin.com/jDHVaNwf (actually, I just added nearly at the bottom one line:
setcookie("cookie_portal", $sessionid);And:
Upload these two files with the FileManager available in the Captive Portal:
style.css - http://pastebin.com/MqwEcxVP (this file will be called and used as captiveportal-style.css when uploaded)
xxxxxxx-already-connected.html - http://pastebin.com/PUyQvAuv (this file will be called and used as "captiveportal-xxxxxxx-already-connected.html" when uploaded)You probably have to change the first part of the last file name = "xxxxxxx" in xxxxxxx-already-connected.html
Edit your instance (zone) of your captive portal. You will find the wanted parted in the URL:
Example, mine is showing this:
http://192.168.1.1/services_captiveportal.php?zone=xxxxxxx
(Note: my first and unique Captive portal zone is being called "ZONE1" - that's NOT the part we wanted)Hi Gertjan, if you're still there I just wanted to know if its working with freeradius auth? I did tried this one. But I guess I'm a bit lost. I don't know where is the Zone thing :'( :'( :'(
The issue is: I've been redirected to the disconnecting page. I was expecting that I may not be able to use the net, but I still can.
-
-
Yes, I'm still here.
You are using Radius -I'm not. So you tell me if everything works with your setup.
This https://github.com/pfsense/pfsense/blob/master/src/usr/local/captiveportal/index.php#L167 should probably be checked out.
Btw :
File: /usr/local/captiveportal/index.php : http://pastebin.com/scYuKTyw - index.php - compare and modify last ~ 15 lines
Basically, this parted gets inserted:This is wrong. The cookie is laso destoyed at line 124 (see pastebin link).
-
Yes, I'm still here.
You are using Radius -I'm not. So you tell me if everything works with your setup.
This https://github.com/pfsense/pfsense/blob/master/src/usr/local/captiveportal/index.php#L167 should probably be checked out.
I also have that line sir. Here's my index link: http://pastebin.com/ZU2TNYeZ - index.php and my inc file: http://pastebin.com/1sD9iZb3
Hope you don't mind checking it out. I'm a bit lost. :'( :'( :-[[quote]
Btw :File: /usr/local/captiveportal/index.php : http://pastebin.com/scYuKTyw - index.php - compare and modify last ~ 15 lines
Basically, this parted gets inserted:This is wrong. The cookie is laso destoyed at line 124 (see pastebin link).
Should i remove that part in my code?
By the way, im in the part when i clicked the "LOGOUT" i am redirected in "Disconnecting" but im still connected.
??? :o -
Hi Gertjan,
Hope you are doing great!
I have tried this in 2.3 but its not working, any modification to make logout working in 2.3
-
Going well here :)
2.3 isn't really different when it concerns the captive portal code.
I guess the patches can be applied when you know that you have to patch the intelligent way : line numbers have changed, some code changes have been made, etc.
You have to know what you patch in, what it does - en what the actual code does.What different is : Knowing that the "lookup-session-with-cookie" method doesn't work (most BOYD devices use bare-bone navigators that do not store the cookie) the "logout"
Added to that : Here in France "Internet" costs about nothing, so I sell it using the same price to my clients (visitors). This implies that people aren't looking to disconnect anymore.So, you can understand that I 'm not looking anymore to have users disconnecting themselves.
(although I have a "disconnect-for-inactivity" very low : 30 minutes).
