Subject: Re: [Captive-portals] Improve the user experience of captive portals as they're commonly understood and currently deployed

From: Michael Richardson <[email-masked]>
Date: Wed, 03 May 2017 08:57:36 -0400

James Wood <[email-masked]> wrote:
    > 4. Walled garden. It's a nightmare having to manage lists of domains/IP's
    > across all the different vendors kit out there. For example to offer a
    > social login through Facebook we need to allow certain domains like
    > facebook.com, akamaihd.net and connect.facebook.net etc. This is all
    > static

It seems that maybe facebook could be more involved here.
I think it's clearly in their interest to make this easier.

    > lists inside an AP/controller, and would be a nightmare to update should
    > Facebook change the URLs they send authentication requests throught etc. How
    > about some way to dynamicly pass back a list of domains as part of the DHCP
    > option or some other way to allow the operator to set the required domains
    > at time of connection? Or, how about, as part of the capport API, we are
    > able to send a list of domains back to the AP, so if someone chooses
    > Facebook, we open the Facebook domains for that MAC for a few minutes to
    > allow them to login.

As Erik and Lorenzo had said, on Android at least, one reason for the captive
browser is because it's the only way to connect to the new network before the
3G is disconnected.
Passing a list of domains to the browser seems like a fail to me.

    > I had a look at "draft-wkumari-capport-icmp-unreach-02". I note that it
    > describes the example URL that could be returned as part of the captive
    > portal URL: https://wifi.domain.com/portal?icmp_session=10&policy_class=100.
    > However, what about the other traditional parameters that a captive portal
    > redirect injects? As a minimum, we need the ap_mac, client_mac and login_url
    > to which we post the login request back to (traditional captive portal login
    > request). Without such parameters, we cannot identify the venue/ap/client
    > and provide the relevant portal splash page and user specific options. I may
    > have misunderstood this?

I think you are missing the point of the URL.  It's not after login, but it's
how to find the login page. Once you have it, you can do anything.  Also, I
think you can include any additional parameters you want. It's descriptive,
not prescriptive.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-