Re: [Captive-portals] Starting to discuss Captive Portals

[Martin Thomson <martin.thomson@gmail.com>]

On 29 April 2015 at 09:49, Warren Kumari <warren@kumari.net> wrote:
> I wanted to get folks views on the interface exposed by chilli (
> http://coova.org/CoovaChilli/JSON ).
> It has a simple "status" page (
> http://192.168.182.1:3990/json/status?lang=en ), but also provides a
> "logon" and "logoff" interface.
> In addition to the state (clientState ) the status page also includes
> idleTime and inputOctets / outputOctets.
> What else do we think the client might need to know? What do folk
> think about the additional interfaces (login / logoff)?


I think that GET requests with side effects like this are dangerous.

More concretely, I think that the following functions are required:

discovery - you need to find who to talk to about these things

status - You need to know what your status is - the identity of this
resource should be learned via discovery.  This needs to be in a
standardized format suitable for machine processing.  This should
include time remaining, and links to the other resources, if they
exist.

logon - you need to know where to log in - this should be a web page,
the location of which is learned from the status resource, and it need
only be present if login is required

logout - if a user is logged in, the status resource might provide
them with a page where they can clear their logout details.  I'd
consider this to be optional.

human-consumption status - a web page that shows status.  I'd consider
this to be optional also.