User:Magick777/WISPr WiFi Autologin
(→Use cases) |
|||
Line 5: | Line 5: | ||
** do we have an IP address? do we have a gateway? | ** do we have an IP address? do we have a gateway? | ||
** can we make an HTTP GET request unimpeded? is this a captive portal? | ** can we make an HTTP GET request unimpeded? is this a captive portal? | ||
- | ** did the captive portal offer us | + | ** did the captive portal offer us WISPr auth? do we have credentials? |
- | + | ||
* Routine auto-login at local FON / IPass / BTWiFi and similar hotspots | * Routine auto-login at local FON / IPass / BTWiFi and similar hotspots | ||
- | * | + | * |
- | + | ||
== Existing WISPr clients == | == Existing WISPr clients == |
Revision as of 09:56, 23 July 2013
This page documents work on automated logins to UK WiFi hotspots, and attempts to achieve native support in the N900 for WISPr auto-login, on any hotspot network that supports it.
Contents |
Use cases
- Testing the currently available WiFi connection
- do we have an IP address? do we have a gateway?
- can we make an HTTP GET request unimpeded? is this a captive portal?
- did the captive portal offer us WISPr auth? do we have credentials?
- Routine auto-login at local FON / IPass / BTWiFi and similar hotspots
Existing WISPr clients
WISPr clients seem to be very few and far between; it's used in network-specific clients such as the BT app, and there are generic clients for Android and iOS, but it hasn't taken off in a big way.
Design goals
My preference is for an event-driven, script-based autologin; whilst turning it into an application might take it to the masses, we then have needless complications of putting a GUI on it, running a daemon to take care of listening for new connections, etc. So, my aim is for a command line client that can be launched from dbus-scripts (or otherwise) on connection to a wireless network.
This client should
- make an HTTP GET request and determine whether we are connected
- determine whether our captive portal supports WISPr
- determine whether we have credentials per login domain
- attempt authentication and determine the response
- support multiple sets of credentials for multiple WISPr captive portals
and may
- record the logoff URL and provide a means to log off
- notify the user of relevant information during the logon process
- generate logs of its activity
- provide a way to try more than one set of credentials for a single portal?
- provide a way to use fallback credentials for a previously unknown portal?
but should not
- interfere with connections to private or non-WISPr WiFi networks
- open any popups or applications that require user interaction
- be too difficult to install, configure, or understand
- involve any large or complex dependencies
Design challenges
* Our WISPr client needs to speak XML, HTTP and HTTPS
- SSL support is not natively present in Maemo 5's perl or python
- Adding SSL support to python requires some SDK libs, see this thread
Option 1: keep python client as it is, using httplib + ssl. Users will just have to install ssl.
Option 2: update python client to use ndg-httpsclient if it works under python 2.5
Option 3: update python client to use pycurl, let libcurl do the fetching & carrying
* We want to be non-interactive, so how do we handle logoff?
Option 1: don't bother, the portal takes care of lost connections anyway.
Option 2: provide manual logoff by saving the logoff URL, only works if we still have a connection