Re: [PATCH 0/5] Handle HTTP error 511

[Dan Williams <dcbw redhat com>]

On Mon, 2013-02-11 at 15:44 -0200, Jonh Wendell wrote:
> 2013/2/11 Dan Williams <dcbw redhat com>
>         On Mon, 2013-02-11 at 12:09 -0200, Jonh Wendell wrote:
>         > From: Jonh Wendell <jonh wendell oiwifi com br>
>         >
>         > This series of patches fixes (on the NM side) bug #670394.
>         
>         
>         Thanks for working on this!
>         
>         One thing I'm wondering is how we'd more quickly see whether
>         the portal
>         login was successful or not so we could change our NM state to
>         show
>         "online connected" instead of behind a portal.  There's two
>         options
>         here:
>         
>         1) check every 5 or 10 seconds for connectivity until
>         connectivity is
>         successful; but this might make some portals angry
>
>
> That's what I'm doing right now. It does *not* make portals angry.
> That's what happen in real life, when someone joins the WiFi and
> thousands of user programs try to reach the internet. What the hotspot
> do is just redirect them and reply the http requests with a 302 Moved.

Very good to know.  So we'll probably just do that then.

> This leads to a discussion which I was expecting to have far
> later :) : should we make connectivity code mandatory (right now it's
> compile-time optional) and use some global machine (something like
> status.gnome.org) to do the check.

We're discussing moving to require glib 2.32 for the next NM release
(danw should post that question very soon), and if we do that, then we
can build the connectivity code by default, but leave it disabled unless
the user/package wants.  The only reason it's not enabled is because
libsoup has some external dependencies we don't want in recent versions,
but that's been fixed already upstream.

>  
>         2) have some mechanism for whatever handles the portal login
>         to indicate
>         to NetworkManager that login was successful, or that NM should
>         reconnect/retry DHCP.  If this is what we want to do, we could
>         move the
>         captive portal stuff into the Agent interface since those
>         processes are
>         somewhat authenticated (as we already ask them for secrets)
>         and they'd
>         theoretically also have access to any portal auto-login
>         credentials.
>
>
> I didn't understand this point. Do we have something already
> authenticated? I guess not. Even if the user already supplied the WiFi
> credentials (WPA, etc) he's still behind a captive portal, and will
> still be redirected.

As we discussed on IRC, I've pushed a proposed Agent API for this to the
dcbw/agent-portal branch:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=dcbw/agent-portal&id=f39d39bc13469b7094366f4099b4e26c6cf51f04

is there anything you'd add/change there?  Remember, this is the method
that NM would call on the thing that's actually handling the portal
display (eg, nm-applet, GNOME Shell, KDE, etc).

One question I had: is it possible that the agent may pass back
secrets/credentials in the future?  eg, if the user types in the
passwords and then checks "save this password" or something, we'll want
to store that, and that means that the agent would have to pass that
back to NM.

Dan

>  
>         Also, I got some captures of a portal in a hotel I was in
>         recently, and
>         for any HTTP request it returned (1) 305 Found with a Location
>         header
>         pointing to the next location, then (2) 302 Moved with another
>         Location
>         header pointing to the actual login page.  In this schemed
>         we'd somehow
>         detect this and then stuff the #2 Location URL into the
>         login-url
>         property I guess?
>
>
> That would be certainly great to have. I'll think on that when
> implementing the 'Moved 30x' thing.
>
>  
>         Dan
>         
>         > Basically we added a new method in the API:
>         CaptivePortalState (), which
>         > returns a boolean indicating whether we are behind a captive
>         portal, and a
>         > string that contains the login url, as supplied by the
>         captive portal.
>         >
>         > The main change is in the internals of NMConnectivity
>         object: We check if the
>         > http status is 511 and the try to discover the login url.
>         Currently we only check
>         > for the url in the <meta> html tag. There's room to improve
>         this in the future.
>         >
>         > Next step will be to patch gnome-shell to make use of this
>         new API and show to
>         > the user a nice UI.
>         >
>         > For convenience, these patches are also hosted on github:
>         > git://github.com/jwendell/NetworkManager.git (branch
>         rfc6585)
>         >
>         > Jonh Wendell (5):
>         >   connectivity: change the "connected" member for a more
>         generic one
>         >   connectivity: Add libxml2 as a dependency
>         >   connectivity: Add the private member login_url
>         >   connectivity: check for http response code 511
>         >   api: Added the method CaptivePortalState()
>         >
>         >  configure.ac                 |  14 +++-
>         >  introspection/nm-manager.xml |  20 +++++
>         >  src/Makefile.am              |   4 +-
>         >  src/nm-connectivity.c        | 190
>         ++++++++++++++++++++++++++++++++++---------
>         >  src/nm-connectivity.h        |  22 +++--
>         >  src/nm-manager.c             |  43 ++++++++--
>         >  6 files changed, 234 insertions(+), 59 deletions(-)
>         >
>         
>         
>         
>
>
>
> -- 
> Jonh Wendell
> http://www.bani.com.br