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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 03 May 2017 13:00 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CC012952D for <captive-portals@ietfa.amsl.com>; Wed, 3 May 2017 06:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_TDqbHRQlM9 for <captive-portals@ietfa.amsl.com>; Wed, 3 May 2017 06:00:26 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056D7129527 for <captive-portals@ietf.org>; Wed, 3 May 2017 05:57:37 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 76BDC2009E; Wed, 3 May 2017 09:23:31 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 436E0636BB; Wed, 3 May 2017 08:57:36 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: James Wood <james.wood@purplewifi.com>
cc: captive-portals@ietf.org
In-Reply-To: <025c01d2b856$a716c030$f5444090$@purplewifi.com>
References: <025c01d2b856$a716c030$f5444090$@purplewifi.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 03 May 2017 08:57:36 -0400
Message-ID: <29955.1493816256@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/KgYAuik_HzQFQPWpoOsDD48ff1s>
Subject: Re: [Captive-portals] Improve the user experience of captive portals as they're commonly understood and currently deployed
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2017 13:00:28 -0000

James Wood <james.wood@purplewifi.com> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-