GNOME Bugzilla – Bug 769692
Captive portal detection login webkit window should bypass any proxy or VPN settings
Last modified: 2017-05-31 14:51:50 UTC
Created attachment 333040 [details] screenshot The captive portal feature is great!.. except when I forgot to disable my proxy in the network settings. Attached is a screenshot of how I got it configured for a SSH tunnel. The problem is that when you resume the computer from sleep, NetworkManager tries to get to, say, a hotel's captive portal auth page, and it can't reach the page because it tries to do it through my configured SOCKS proxy, which isn't up because we haven't gone through the captive portal. Result: I end up with a blank webkit window and no indications. This is on Fedora 24.
NetworkManager only has a feature to periodically fetch a website to determine that the request was hijacked by a captive portal. This process does not use HTTP proxies, but it uses the default routing of the system. Thus, it has first to set the default-route to the Wi-Fi device (thereby possibly borking your connectivity), and only then detects the portal. That should be imporoved. Anyway, afterwards it indicates the presence of a portal on it's D-Bus interface, and other components (like gnome-shell) take it from there to show a popup and a login-page. Thus, the "blank webkit window" does not come from NetworkManager. Reassigning bug.
We should force the webkitgtk view to use empty proxy settings. I'm not sure that we should get a popup if there is already a connection to the internet though. Thomas, would that be a NetworkManager RFE?
(In reply to Bastien Nocera from comment #2) > I'm not sure that we should get a popup if there is already a connection to > the internet though. Thomas, would that be a NetworkManager RFE? sorry, I don't follow. Could you elaborate?
(In reply to Thomas Haller from comment #3) > (In reply to Bastien Nocera from comment #2) > > I'm not sure that we should get a popup if there is already a connection to > > the internet though. Thomas, would that be a NetworkManager RFE? > > sorry, I don't follow. Could you elaborate? Unless I'm mistaken, the global connectivity property isn't set to "portal" when there's already a working connection to the internet. For example, if you're connected to both a wired and a wireless network, and the wired network doesn't have a captive portal but the wireless network does, what would the global connectivity be set to? Anyway, this is probably unrelated.
Created attachment 352108 [details] [review] portalHelper: Don't go through proxies for captive portals When using an SSH tunnel (through a SOCKS proxy) to funnel all the outgoing traffic, we need the captive portal to not go through that proxy, otherwise we can't go through the proxy because we're not connected to the Internet and we can't go through the portal because we're not connected through the proxy. This fixes a blank captive portal window and no error reporting in that particular configuration.
Completely untested but quite trivial patch.
Thomas, do you agree that it would be appropriate for GNOME Shell's portal helper to ignore system proxy settings? While this could fix Jeff's use-case, I wonder if it could break others. I was tempted to say that sometimes a proxy is mandatory, but I suppose in such cases a captive portal is unlikely.
(In reply to Bastien Nocera from comment #5) > This fixes a blank captive portal window and no error reporting in that > particular configuration. This seems like a separate problem. We should display an error message when the load fails. We should also find some way to indicate if the load is still in progress.
(In reply to Michael Catanzaro from comment #8) > (In reply to Bastien Nocera from comment #5) > > This fixes a blank captive portal window and no error reporting in that > > particular configuration. > > This seems like a separate problem. We should display an error message when > the load fails. We should also find some way to indicate if the load is > still in progress. You'll need to file a separate patch about that. As far as I'm concerned, error reporting is a separate problem, and a much bigger one at that. (In reply to Michael Catanzaro from comment #7) > Thomas, do you agree that it would be appropriate for GNOME Shell's portal > helper to ignore system proxy settings? While this could fix Jeff's > use-case, I wonder if it could break others. > > I was tempted to say that sometimes a proxy is mandatory, but I suppose in > such cases a captive portal is unlikely. I'd say bypassing it is a requirement, seeing as NetworkManager doesn't use it for poking the Internet either.
Review of attachment 352108 [details] [review]: ::: js/portalHelper/main.js @@ +144,3 @@ this._webContext = WebKit.WebContext.new_ephemeral(); this._webContext.set_cache_model(WebKit.CacheModel.DOCUMENT_VIEWER); + this._webContext.set_network_proxy_settings(WebKit.NetworkProxyMode.MODE_NO_PROXY); This is the right way to achieve the behavior you want, assuming that the last parameter to this function is optional in the gjs bindings and also defaults to null. (Otherwise, I expect it would trigger warnings in the journal, since WebKit does check to make sure that you pass a null WebKitNetworkProxySettings*. I don't know, so I would check for that.) I still recommend waiting for confirmation from Thomas that this is advisable, since I don't know.
I would agree that bypassing proxy is the right thing for portal login. But don't quote me on that :)
(In reply to Michael Catanzaro from comment #10) > Review of attachment 352108 [details] [review] [review]: > > ::: js/portalHelper/main.js > @@ +144,3 @@ > this._webContext = WebKit.WebContext.new_ephemeral(); > this._webContext.set_cache_model(WebKit.CacheModel.DOCUMENT_VIEWER); > + > this._webContext.set_network_proxy_settings(WebKit.NetworkProxyMode. > MODE_NO_PROXY); > > This is the right way to achieve the behavior you want, assuming that the > last parameter to this function is optional in the gjs bindings and also > defaults to null. (Otherwise, I expect it would trigger warnings in the > journal, since WebKit does check to make sure that you pass a null > WebKitNetworkProxySettings*. I don't know, so I would check for that.) Yeah: (gnome-shell-portal-helper:5923): Gjs-WARNING **: JS ERROR: Error: Too few arguments to method WebKit2.WebContext.set_network_proxy_settings: expected 2, got 1 and after fixing the missing arg: (gnome-shell-portal-helper:8022): Gjs-WARNING **: JS ERROR: Error: Expected type enum for Argument 'proxy_mode' but got type 'undefined' Both fixed and tested in the patch.
Created attachment 352953 [details] [review] portalHelper: Don't go through proxies for captive portals When using an SSH tunnel (through a SOCKS proxy) to funnel all the outgoing traffic, we need the captive portal to not go through that proxy, otherwise we can't go through the proxy because we're not connected to the Internet and we can't go through the portal because we're not connected through the proxy. This fixes a blank captive portal window and no error reporting in that particular configuration.
Attachment 352953 [details] pushed as c22287b - portalHelper: Don't go through proxies for captive portals