[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 30 March 2015 at 15:14, Warren Kumari <[email protected]> wrote:
I suspect that we are going to be spending a significant amount of our
time with the tension between making the user's life better, and also
trying to maximize the CP operator's desires.
Obviously, because the technical concerns aren't what is hard here.

We should specify behavior of both the CP and the client. Specifically, the client MUST display the CP's web page. And hope that most people obey the rules, otherwise we will get into another race between OS vendors and CP vendors.
And this is my fantasy solution:

/.well-known/captive/status - returns a basic status (CP open/closed), and optionally, an expiration time for this information, i.e. when you need to poll the status again.
/.well-known/captive/refresh - returns null if no user action is needed
(rare), or a URL the browser needs to display for the user to beg/pay
for more time.
The browser could detect these well-known URLs in order to notify the
rest of the system, or we could wrap them in some fancy JavaScript.
We should still use DHCP to return the address of the resource, so that
the CP does not need to proxy all IP traffic (it can just drop it, hooray).
Thanks,
	Yaron