On Sun, 4 Dec 2016, Michael Catanzaro wrote:
On Sun, 2016-12-04 at 16:39 -0500, Paul Wouters wrote:
That is a different issue. And indeed I see it as well, and was quite
surprised at them checking the TLS validity of a captive portal page.
We have no plans to stop doing this, because that's how all other
browsers and operating systems work. It shouldn't be any problem
because such portals would not work for anyone on any system.
That is incorrect in my experience. When I go to coffee shops, my iphone
shows the portal page, but my laptop shows the TLS cert invalid thing.
But in this specific case with the gnome-shell portal helper, there
seems to have been a problem because we tried to load an https:// URI
rather than an http:// one, which isn't going to work under a captive
portal as the portal can't replace the page. I really do not completely
understand what the actual bug here was, and nobody seems to have
figured it out, but it seems that for whatever unknown reason some
captive portals decide not to intercept our load of http://www.gnome.or
g. That URI recently became a redirect to https://www.gnome.org, so the
portal helper performs the redirect and then the portal does intercept
the load of https://www.gnome.org, and that's why you get a TLS error.
It's really weird; I don't know why the portal would do that. Moreover
the issue affected some users, but not others, with the exact same
captive portal, using the exact same version of Fedora; we had this
issue at GUADEC. Maybe the redirect is cached by WebKit on certain
systems so it only works if you haven't visited http://www.gnome.org
before in the portal helper...? Anyway, we have "fixed" this by
changing it to load http://nmcheck.gnome.org which never redirects to
HTTPS. I haven't heard any complaints about this since then, so I think
it's good, but the change is in gnome-shell-3.22.2-2.fc25 which is very
recent so let's wait and see.
Yes. That is why I specifically requested that the fedora hotspot page
never chage their output and never send a redirect. Using the main page
of gnome was a bad fit. Note you should also ensure that nmcheck.gnome.org
has a cache lifetime of 0 seconds to it.
I have that on top of the bug where it just shows me the gnome page
instead of the actual captive portal page.
This really requires a separate bug report against gnome-shell.
Probably a race condition somewhere, maybe the last redirect and
NetworkManager connectivity check occurs just before we get
connectivity back. Unfortunately this is an undermaintained component
that is not very likely to be fixed without a volunteer.
Or a cached page? It's been happening to me on f24 for a few weeks now.
Paul
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
