User:Magick777/WISPr WiFi Autologin
(→Methods) |
(→Methods) |
||
| Line 6: | Line 6: | ||
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. | 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 on connection to a wireless network. | + | 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 | + | This client '''should''' |
* make an HTTP GET request and determine whether we are connected | * make an HTTP GET request and determine whether we are connected | ||
* determine whether our captive portal supports WISPr | * determine whether our captive portal supports WISPr | ||
| - | * determine whether we have credentials | + | * determine whether we have credentials per login domain |
* attempt authentication and determine the response | * attempt authentication and determine the response | ||
| - | |||
| - | |||
* support multiple sets of credentials for multiple WISPr captive portals | * support multiple sets of credentials for multiple WISPr captive portals | ||
| - | but should not | + | 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 | ||
| + | |||
| + | but '''should not''' | ||
* interfere with connections to private or non-WISPr WiFi networks | * interfere with connections to private or non-WISPr WiFi networks | ||
* open any popups or applications that require user interaction | * open any popups or applications that require user interaction | ||
| + | * be too difficult to install, configure, or understand | ||
| + | |||
| + | == 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 [http://talk.maemo.org/showpost.php?p=1326179&postcount=7 this thread] | ||
| + | * We want to be non-interactive, so how do we handle logoff? | ||
== Sources == | == Sources == | ||
See also http://talk.maemo.org/showthread.php?t=90777 | See also http://talk.maemo.org/showthread.php?t=90777 | ||
Revision as of 09:09, 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 |
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
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
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
- We want to be non-interactive, so how do we handle logoff?