Captive portal manual logout page address

Gertjan

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

EMWEE

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.

EMWEE

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

I NEVER touch or control devices of our clients (the BYOD owners)

Maby not everyone is using the logout option.

Gertjan

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.

EMWEE

Hmm i dont understand the idea behind this… :(

EMWEE

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.

doktornotor

@Gertjan:

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

Gertjan

@EMWEE:

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.

http://php.net/manual/en/function.setcookie.php
Look at this part in the 'expire' condition: " …. If set to 0, or omitted, the cookie will expire at the end of the session (when the browser closes). "

Knowing now that we deal with two browsers, the junk browser [doktornotor ;)] and the real APP afterwards, I thought : what if they DO share their cache ? what if the first closes (as you said) then I could consider this as a 'session close' …. and the cookie would be destroyed.
So I use the hard timeout limit (we set it in minutes, I convert to seconds) , if its present. If none is present, then, well, 'expire' stays '0' - as default.

https://support.ruckuswireless.com/answers/000002368 tells a lot about Apple's CNA: it probably doesn't takes the cookie. Other smartphones, other CNA's: same issue.

EMWEE

So the Captive Portal Assistant (pseudo browser) shares the cookies with your other browers?

Gertjan

@EMWEE:

So the Captive Portal Assistant (pseudo browser) shares the cookies with your other browers?

Noop. Guess not. See my last message …. I edited.

EMWEE

Right, think im gonna switch to the less secure IP/MAC option.

doktornotor

@EMWEE:

So the Captive Portal Assistant (pseudo browser) shares the cookies with your other browers?

No. It's like a crippled "anonymous" browser, no cookies saved, no javascript either AFAICT. The Apple support forums are full of complaints about this nonsense (additionally, it gets gradually worse with every new OS release.

EMWEE

GertJan do you have some new links on the pastbin files for your IP/MAC solution?

My already_connected function works…but it seems it can resolv #PORTAL_SESSION#

So I guess I need to add the $htmltext = str_replace("#PORTAL_SESSION#", htmlspecialchars($sessionid), $htmltext);

amitaussie

@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

Hi EMWEE,

Thanks for your reply.

I am trying to work this solution on LAN interface, but authentication page is not showing, may be I have settings in Firefox " Do no remember history" I ll change this to normal setting and ll try if it works then…

Regards

amitaussie

EMWEE

Does your captive portal works without the modifications?

U should get your AUTHENTICATION page by default. So if that doesnt work your captive portal doesnt work out of the box…or u made a mistake in index.php...what would result in a error in your browser.

Maby post your complete index.php and captiveportal.inc on pastebin and share in it this topic.

amitaussie

Hi EMWEE!

Client is not able to connect to internet if CP is active on LAN interface in pfSense and url on client shows this:

http://192.168.100.1:8002/index.php?zone=cpzone1&redirurl=http%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A%2F%2F%2Fhttp%3A

and gives this message in page - The page isn't redirecting properly

If I do not make changes in pfSense, CP page is showing for authentication on LAN and pop up for log out is working ok.

below are the files…

/etc/inc/captiveportal.inc- http://pastebin.com/BUstXyr1

/usr/local/captiveportal/index.php- http://pastebin.com/ffj69qAb

Index.php file is copied from Gertjan's pastebin

File: /usr/local/captiveportal/index.php : http://pastebin.com/scYuKTyw - index.php

Thanks and Regards

amitaussie

EMWEE

Do you have a html file with the name "zone"-already-connected.html? (ex. Wifi-already-connected.html)

If your users have a cookie they are redirected to that page.

amitaussie

Hi EMWEE!

Yes I have uploaded that file in CP using File Manager. File I uploaded is copied from Gertjan's pastebin

I am using default setting of browsers i.e. firefox. Browser is configure to remember history and accept cookies.

I do not understand how to users have cookie

If your users have a cookie they are redirected to that page.

Thanks & Regards

amitaussie

Gertjan

He (amitaussie) PM'ed me with this:
CP Tab: file Manager status:

            captiveportal-cpzone1-already-connected.html    984 bytes    delete
            captiveportal-style.css                           2 KB       delete
                     TOTAL                                    3 KB

seems good to me.

I'm put in place his
/etc/inc/captiveportal.inc- http://pastebin.com/BUstXyr1
/usr/local/captiveportal/index.php- http://pastebin.com/ffj69qAb

on my pfsense - and report back.

edit.
Ok, found something - your /usr/local/captiveportal/index.php is nearly ok.
This : http://pastebin.com/ffj69qAb when I upload it to my server, produces a file coded in "UNIX - UTF 8 w/o BOM".
Should be "UNIX ANSI."

Your http://pastebin.com/ffj69qAb does not popup the portal page for me.
I rebuild http://pastebin.com/scYuKTyw - /usr/local/captiveportal/index.php - entire file - version 2015-02-06 : I took an original "index.php from https://github.com/pfsense/pfsense/blob/RELENG_2_2/usr/local/captiveportal/index.php [ PfSense 2.2 Release ] - added my 2 mods - tested on my pfSense and stored on pastbin.org :: http://pastebin.com/scYuKTyw ]

Btw: I found out that when coping back the files from pastebin.org to my text editor it converted ther char encoding "UNIX UTF w/o BOM" (there are some nasty non-pure ASCI chars in the file).
Saving the file (example: index.php) in this format will 'explode' the pfSense web server.
ALWAYS check you code page : often this info is visible at the bottom of your text editor (Notepad++, or far better : UltraEdit)

amitaussie

Hi Gertjan!

Thank you very much for your effort.

I ll check it tomorrow and revert back.

Thanks & Regards

amitaussie