GNOME Bugzilla – Bug 704416
handle portal login requests for NM
Last modified: 2014-06-26 17:56:29 UTC
NM has (or will soon have) a form of captive portal detection. A captive portal basically uses a web page as network login interface instead of using one of the network level authentication schemes. So, instead of a WAP/WEP/etc dialog popping up - a proxy web page will pop up. Something has to pop up this page. Seems like since the shell already does the other auth dialogs it should at least be involved in this one too. The user experience should be very simple. A chromeless web view that loads the portal login page. It should close when the connection has been successful (even if done out of band) or the user cancels the request. We probably want to treat this case in a similar way to how we treat the WAP/WEP login prompts. Modally. I think it may be fine to use a chromeless, maximized window for this. It should probably remember login details for next time. Apparently there are some cases where the auth can be done automatically. I don't think we want to add an explicit dependency on any particular web browser application. So maybe we can just add a little helper tool that uses a webview directly. Technical details: Watch the :state property on the NMClient. if it's NM_STATE_CONNECTED_SITE, then NM believes you're behind a portal Many portals implement WISPR/Hotspot2 which embeds some XML in the page which tells you how to auto-login if you have credentials.
The NM interface for this is expected to be as follows: 1) The Agent D-Bus (and libnm-glib) API will be extended with a CaptivePortal interface; a rough-draft of that API is http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=dcbw/agent-portal&id=f39d39bc13469b7094366f4099b4e26c6cf51f04 2) NM will call various methods on the Agent's new CaptivePortal interface when it's reasonably sure that its behind a portal 3) the Agent will do whatever is necessary to authenticate to the portal, like show a webview and allow the user to log in manually, or parse the WISPR response and automatically login with saved credentials 4) the Agent returns a status code to NM indicating success/failure/whatever, and NM performs another connectivity check to see if you're now online or not
Technical limitation: we can't embed webkit inside the shell UI. I'm afraid the only reasonable way to implement it is to spawn epiphany (or the configured browser) with the URL we get from NM. But in that case, we can't make it modal, because there is no system modality unless you take an X grab, which causes its own set of problems (like not locking the screen, or not having keybindings).
No I don't think we should spawn epiphany. But making a helper binary that uses a webview is trivial right? Surely we can find some way to make this appear modal and not worry about that stuff. A maximized window that is on top of the z-order should be fine right?
On the NM side, some things are in place in F20. We just need to create /etc/NetworkManager/conf.d/gnome.conf: [connectivity] url=http://somewhere.online.org/online where the online file has the following contents: NetworkManager is online With this, in place, NMClient::connectivity gets set to one of these values: * @NM_CONNECTIVITY_UNKNOWN: Network connectivity is unknown. * @NM_CONNECTIVITY_NONE: The host is not connected to any network. * @NM_CONNECTIVITY_PORTAL: The host is behind a captive portal and * cannot reach the full Internet. * @NM_CONNECTIVITY_LIMITED: The host is connected to a network, but * does not appear to be able to reach the full Internet. * @NM_CONNECTIVITY_FULL: The host is connected to a network, and * appears to be able to reach the full Internet. I think we probably want to indicate LIMITED/PORTAL with some different icon, and use a notification that offers to launch the helper binary ?
Created attachment 269460 [details] [review] Add a helper to handle captive portal logins Add a small DBus-activated GtkApplication that embeds a WebKitWebView and implements some minimal logic to see if the login succeeds.
Created attachment 269461 [details] [review] NetworkManager: show portal logins when required Listen to changes in connectivity, and ask our helper to authenticate when needed. We don't have a URL to connect to yet (we will have when the new NM API lands), so we use the default of trying www.gnome.org (which is also more reliable because we can recognize when the login is done)
This is without the notification, it spawns right away, like the original report asked for (and like what Mac OS X does). It was tested in LIMITED connectivity conditions, not under an actual portal, but it should work. I'm attaching it now because of UI freeze. Also note that without property NM configuration, this is completely ignored (NM will always report 4), and without bug 724550 the experience is poor (NM reports limited connectivity even for fully connected networks)
Review of attachment 269460 [details] [review]: Didn't test it but code looks good to me just some minor stuff noted below. ::: js/portalHelper/main.js @@ +111,3 @@ + + let now = GLib.get_monotonic_time(); + let shouldRecheck = (now - this._lastRecheck) > 30 * GLib.USEC_PER_SEC; Should use a constant. @@ +148,3 @@ + this.parent({ application_id: 'org.gnome.Shell.PortalHelper', + flags: Gio.ApplicationFlags.IS_SERVICE, + inactivity_timeout: 30000 }); Constant as well. @@ +220,3 @@ +function initEnvironment() { + // Monkey-patch in a "global" object that fakes some Shell utilities + // that ExtensionUtils depends on. What does this have to do with ExtensionUtils? @@ +221,3 @@ + // Monkey-patch in a "global" object that fakes some Shell utilities + // that ExtensionUtils depends on. + window.global = { This seems unused? @@ +233,3 @@ + }; + + String.prototype.format = Format.format; This too. ::: src/gnome-shell-portal-helper.c @@ +29,3 @@ + &error)) + { + g_message("Failed to defined ARGV: %s", error->message); "define"
Review of attachment 269461 [details] [review]: Code looks good. The commit message talks about testing with gnome.org but this is done in the other patch. Should be reworded.
NM 0.9.10, which should be out soon (and is in Rawhide almost already), has working connectivity support, so it's a good time to push this. All review comments addressed. Tested in LIMITED environment and under a real captive portal. Attachment 269460 [details] pushed as 8c67a70 - Add a helper to handle captive portal logins Attachment 269461 [details] pushed as 47c9243 - NetworkManager: show portal logins when required