Captive portal manual logout page address

lsense

This means a cookie will be communicated to the browser when the portal clients succeeds authentication ?
edit: btw, from where did you send the cookie ? From /etc/inc/captiveportal.inc : end of function portal_allow() ?
If so, when:
@lsense:

modify index.php to check if redirection url is http://logout.me and check session cookie (you have to auth again to logout if you close the browser but not just the popup.)

then correct, the session gets reused!

I set logout cookie in /etc/inc/captiveportal.inc function portal_allow() as simply as:


/* set logout cookie */	
setcookie("logout", $sessionid);

then in /usr/local/captiveportal/index.php:


...
else if ($redirurl == 'http://logout.me/') {
	if (isset($_COOKIE["logout"])) {
		$logoutcookie = $_COOKIE["logout"];
		setcookie("logout", "", time() - 3600);
		echo << <eod<br><title>Disconnected</title>

 **Disconnected.** 

EOD;
		captiveportal_disconnect_client($logoutcookie);
	}
	else {
	captiveportal_logportalauth('failed, missing cookie: reauth',$clientmac,$clientip,"LOGOUT");
	portal_reply_page($redirurl, "login",null,$clientmac,$clientip);
	}
}</eod<br>

Gertjan

As lsesne proposes, I have it working with cookies now.
No more IP and MAC posting.

Note: If portal visitor doesn't like cookies (read: he won't be doing much on the Internet) the discussed logging method won't work.

edit: lol: I was just posting the above when lsesne posted.
I created and destroyed the cookie in the same places !!

I destroyed like this:

Gertjan

Here are my modifications that work with cookies:

Modify these files:
The entire file: /usr/local/captiveportal/index.php : http://pastebin.com/yJirfya6 (includes latest updates from https://github.com/pfsense/pfsense/commit/1b244d3828e83d3c1677d88d5c6bfcb34debac83 )

/etc/inc/captiveportal.php :

Replace the entire function portal_reply_page(…) with this one : http://pastebin.com/wjWXea06
Just above this new function portal_reply_page(…), add this new function already_connected(…) : http://pastebin.com/x3fxwEf8
Replace the entire function portal_allow(…) with this one : http://pastebin.com/ivzjTuns

And:
Upload these two files with the FileManager available in the Captive Portal:
style.css - http://pastebin.com/LqLx9G5f
already-connected.html - http://pastebin.com/p8GRpuHQ

CrackBlue

@Gertjan:

Here are my modifications that work with cookies:

Modify these files:
The entire file: /usr/local/captiveportal/index.php : http://pastebin.com/yJirfya6 (includes latest updates from https://github.com/pfsense/pfsense/commit/1b244d3828e83d3c1677d88d5c6bfcb34debac83 )

/etc/inc/captiveportal.php :

Replace the entire function portal_reply_page(…) with this one : http://pastebin.com/wjWXea06

Just above this new function portal_reply_page(…), add this new function already_connected(…) : http://pastebin.com/x3fxwEf8

Replace the entire function portal_allow(…) with this one : http://pastebin.com/ivzjTuns

And:
Upload these two files with the FileManager available in the Captive Portal:
style.css - http://pastebin.com/LqLx9G5f
already-connected.html - http://pastebin.com/p8GRpuHQ

Any new updates on pastebin? it seems that pastebin has already removed the entries…

Gertjan

Sorry.

…. I've updated to the latest pfSense without any 'copies' of the modified files mentioned above.

:(

Gertjan

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)

Btw: @lsense, if you are there:

host override in dns forwarder : logout.me -> 1.1.1.1

Ok, done.

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 ?

EMWEE

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?

Gertjan

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.

EMWEE

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.

Gertjan

@EMWEE:

….
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#msg422179

But, 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.

EMWEE

Thanks GertJan, got it working now :)

Gertjan

I'll give it a try to 'backport' all this to pfSense 2.2 Release.
I'm pretty sure its possible.

EMWEE

Got it working on 2.2. Just do the same thing :)

Gertjan

@EMWEE:

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.

amitaussie

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

Gertjan

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

EMWEE

@amitaussie:

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

Gertjan

@EMWEE:

@amitaussie:

I am not using https CP.

It works on http.

Guide is on de previous page.

Thanks for the info :)

EMWEE

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.

Gertjan

@EMWEE:

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).