David Bird <[email protected]> wrote:
> To clarify, there is a CP access controller (let's call this CP-NAS)
> and a CP web application (and this CP-WEB). The DHCP option could
> return the IP address of the CP-NAS (if not the same as the default
> gateway). We can then define a .well-known URL, such as
> http://CP-NAS/.well-known/capport-redirect, which the client can use to
so, in this context, "CP-NAS" would be an IP address literal?
(I ask, because there are lots of portal vendors who think that DNS search
strings work, and might use a literal "cp-nas"...)
> learn the (possibly device and session specific) URL to the CP-WEB
> application. The CP-NAS URL is always HTTP and only does a 302 redirect
> to the CP-WEB application. This provides a convenient and standard way
> for the client to pick-up the CP-WEB URL (with all necessary query
> string parameters added by the CP-NAS) without having to "guess" a URL
> outside of the walled garden or wait for the user to visit a HTTP
> site. The CP-WEB URL can, and should, be HTTPS if handling any user
> data (though, perhaps not a MUST as a Terms of Service only wouldn't
> necessarily require https).
It does require https, because the browser and end user have to be sure that
they reached the right web site.
> * Note: CoovaChilli already has this type of internal URL
Is CoovaChilli still alive as a project, btw? It was unclear to me last time
> I'm not sure it belongs in RFC, but ideally, I'd like to see Clients
> NOT use a limited (sandbox) browser when a CP-WEB is using HTTPS.
The logic is that you don't give strangers your cookies, or your
HTTP Basic Authentication headers.
With HTTP, we have no control over what name maps to what server (because
HTTP is trivially hijackable), so one would send any cookies one might have
for that FQDN.