Hi David, I am not too familiar with CoovaChili internals, does the hijacking routine add the string params(station/session) to the DHCP option or is it scripted to use the option82 data and add the parameters after the user goes to http://<nas-ip>:<port>/prelogin?
On Fri, Aug 26, 2016 at 2:00 PM, David Bird <db...@google.com> wrote: > RFC 7710 says, ".. provides the URI to access an authentication page." > Obviously, this will need further clarification should it point to an API > end-point. As it is written, I think it is clear that the URI should be the > same (or will redirect you to the same) URL as a HTTP hijack takes you to > (minus any "original URL"). > > In CoovaChilli, at least, there is already an internal/local URL that is > suitable for RFC7710. In that the URL http://<nas-ip>:<port>/prelogin in > chilli hooks into the hijacking routine to redirect the user to the captive > portal URL specific to them (e.g. the hijacking routine adds the query > string params specific to station/session). > > https://github.com/coova/coova-chilli/pull/274/commits/ > 1e95a2cf97e981f2f53826e38cd12372555a809c > > > On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson <ddol...@sandvine.com> > wrote: > >> Alexander, >> >> Suppose instead of providing a URL for the landing page, the RA provided >> the URI for a standardized REST interface; the client could post its >> details (MAC address, device type?) to this interface, which would return >> the URL for the browser landing page, and possibly any number of other >> details and mechanisms, e.g., in a JSON response. >> >> >> >> This adds a level of indirection that simplifies what needs to go in the >> RA. >> >> >> >> I think there is also flexibility in letting the client know details >> about the capport situation in the API. E.g., how often will the page need >> to be visited? >> >> >> >> RA-->client: “This is the URI for getting capport info: >> http://capport.example.com/api” >> >> Client-->capport/api: “My MAC address is 01:02:03:04:05:06 and my IP >> address is …” >> >> Capport/api-->client: “Your landing page is >> https://capport.example.com/landing/mac=01:02:03:04:05:06 ; refresh >> every 60min” >> >> >> >> >> >> >> >> -Dave >> >> >> >> >> >> *From:* Captive-portals [mailto:captive-portals-boun...@ietf.org] *On >> Behalf Of *Alexander Roscoe >> *Sent:* Friday, August 26, 2016 11:15 AM >> *To:* captive-portals@ietf.org >> *Subject:* [Captive-portals] IPv6 RA URI option >> >> >> >> I am looking over RFC 7710 <https://tools.ietf.org/html/rfc7710> >> concerning how the URI is communicated to the end user. I really like the >> IPv4 DHCP solution, I think this could easily be implemented in a DHCP >> server. I think it could be easily implemented in the RA for IPv6 as well >> however I do see a challenge when each connected client needs a unique URI >> such as it containing the parameter for the client mac. For example, a url >> like https://captiveportal/?client-mac=11:22:33:44:55:66. The RA is sent >> to everyone and cannot be tailored to each client while DHCP is very client >> specific and can be changed on-the-fly. Most captive portals rely on the >> client mac address during the authentication process. I am aware of >> networks using the IP address to associate the user at the AAA server but >> from my understanding this is a rare network setup. I think a potential >> solution for the IPv6 RA would be to define an HTTP POST parameter in which >> the client can use like ‘client-mac’ and let the client post it the URI >> https://captiveporta/. Thoughts? Ideas? >> >> >> -- >> Alexander Roscoe >> 484-716-9048 >> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals >> >> > -- Alexander Roscoe 484-716-9048
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
