[feature-request] WiFi Captive portal auto-login

asked 2014-10-30 12:47:41 +0300

dsilveira
7805 ●77 ●110 ●101

updated 2016-08-17 11:00:50 +0300

jiit

2678 ●32 ●58 ●59

admin

What I'm proposing is to improve Sailfish users' experience when connecting to the internet through a captive portal WiFi hotspot.

How I propose we do this is:

step 1 - to have an option, when on the wifi available networks screen, and you select a certain open network for connection, an option to set this network SSID has a captive portal authentication one,
step 2 - in which case login credentials are requested, as if the network was not open. (which in reality is not)
step 3 - Sailfish internally opens (and keeps it open) the captive portal authentication webpage,
step 4 - Sailfish, through scrapping, detects the login fields and submit button on the internally open page,
step 5 - Sailfish, automatically enters the given credentials and submits them to get proper access to the network

In case of being unsuccessfull which would be detected through failure to access some predictable web location (maybe a Jolla web-service), and only then, present the Sailfish user with the internally opened captive portal web page, for manual intervention.

If, even after manual intervention, the network access is still failing, disable that network connection, so that the user knows it is not actually connected to the network.

In case of successfull connection established the credentials should be saved, just like any other closed network, and in the future automatically go through the whole login process internally before considering the network as connected.

Conclusion: this would make the captive portal authentication transparent to the user, which would be very practical, instead of the current upractical behaviour of needing to open the browser (and keep it open) and loging in to the web page manually!

related to this (altough what I'm asking is a bit more automatic, and also that question was getting really off topic).
also related to this (altough, that one is a bit vague, and going nowhere anytime soon)

edit retag flag offensive close delete

Comments

This is a very good idea.

richardski ( 2014-10-30 12:55:24 +0300 )edit

Thank you, I thought it is so simple and practical that it should be easy to implement by Jolla, and would make the users of captive hotspots very happy

dsilveira ( 2014-10-30 18:35:05 +0300 )edit

@dsilveira - In our office premises, food court provides a free public wi-fi service that also prompts to agree to their terms ( 'Agree' & 'I do not agree radio buttons') other than entering credentials. Just curious, how you imagine fields could be populated? BTW, didnt know the term 'captive portal' till sometime ago. So I looked upon wiki which says that in some cases even payment maybe required. Not sure, how it could be handled.

anandrkris ( 2014-12-10 15:39:10 +0300 )edit

those cases you mention are rare, compared to login-only access, You usually pay for the login and that's it. But if there are a few more common cases than the one I'm describing, they could also easily be accomodated.

dsilveira ( 2014-12-17 03:14:27 +0300 )edit

This would be nice to have. I am regularly encountering two captive portals, my school (where I am daily and have no idea why is there captive portal while everyone has the same username and password) and some buses (at least once in a month) which just wants me to click "I agree the terms and conditions".

The school captive portal is apparently also forgetting me very often and that is why I started googling if this was possible.

Mikaela ( 2015-01-20 10:16:45 +0300 )edit

2 Answers

Sort by » oldest newest most voted

answered 2014-10-31 02:47:21 +0300

tigeli

9543 ●111 ●112 ●130

admin

There is a "standard" called wispr to do this, however there are too many ap/hotspots's announcing that they are supporting wispr even are broken/misconfigured with it.

Also disconnecting connection when you think it is not working is really hard to detect and would lead mistakenly disconnected situations (intranets/internet/not each node is 100% conneceted to all nodes).

From security point of view I'm not really eager of sending user credentials automatically just to any hotspot portal eg. most of them are using self-signed certs or no seurity at all. Rogue-ap's.. yeah, easy-way to capture your credentials.

But anyways, thanks for your input. We will consider if there is anything we could do better.. :)

edit flag offensive delete publish link

Comments

Altough there might be a standard, if as you say, it is not universal, and those that do implement it many times are broken, then I guess that standard is not reliable, and cannot be trusted.

What I propose is independent of login standards, every captive portal has an http login page, so it is eligible to the automation method I describe.

Furthermore, When you say you're not confortable in sending your credentials to access the internet through a captive portal, then I guess you've either never used a captive portal, or you didn't read my proposal carefully, since what it describes is a method that has the exact same security that the manual entering does (even for the rogue SSID clone AP, the vulnerability is the same, but if you wished to improve a bit on this you could make these kinds of network not connect automatically by default).

Has for the disconnect that you describe, you definately didn't read my proposal, since I'm talking about captive portal hotspots (obviously for internet access), so I don't see how having a web service confirm the connectivity would be hard to use for connectivity detection.

Think about it a little more carefully, are you sure you're not just seing problems were there are none?

dsilveira ( 2014-10-31 03:21:58 +0300 )edit

@dsilveira I did read your proposal and I still disagree. :)

Security: there is a difference whether you are sending creds automatically or not.. but yes this could be optional.

Captive portal hotspots: I've seen them being used in networks without internet access. :)

tigeli ( 2014-10-31 03:36:00 +0300 )edit

I'm not either saying this couldn't be done. ;)

tigeli ( 2014-10-31 03:39:36 +0300 )edit

In relation to security, Indeed the difference is faint, but that could be solved by the don't-connect-by-default option (which should already be available to any Wifi network).

In relation to captive portal without internet access, that is not the goal of my proposal, although I can see how people would want to use this feature for that use-case aswell. Once again, what you're describing is a very narrow use-case, and as such should only be supported by an additional option to set it as an intranet connection (maybe on a context menu on the credentials entering dialog)

dsilveira ( 2014-10-31 14:14:52 +0300 )edit

answered 2015-05-03 23:10:31 +0300

ddelamarre
41 ●4 ●4

Updating that : there used to be an application on maemo named autofreewifi for that precisely.

Has anyone considered porting it?

Regards

edit flag offensive delete publish link

[feature-request] WiFi Captive portal auto-login

Comments

2 Answers

Comments

Question tools

Stats

Related questions

[feature-request] WiFi Captive portal auto-login

Comments

2 Answers

Comments

Question tools

Public thread

Stats

Related questions