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

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
        "online connected" instead of behind a portal.  There's two
        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 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

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:

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.


        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
        pointing to the next location, then (2) 302 Moved with another
        header pointing to the actual login page.  In this schemed
        we'd somehow
        detect this and then stuff the #2 Location URL into the
        property I guess?

That would be certainly great to have. I'll think on that when
implementing the 'Moved 30x' thing.

        > 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:// (branch
        > 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()
        >                 |  14 +++-
        >  introspection/nm-manager.xml |  20 +++++
        >  src/              |   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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]