Browser extension verification pre-empts local captive network login?
While trying to log on to a local Wi-Fi network this morning (coffeehouse down the street) via its captive login screen so as to enter a temporary password code that I was given, I noticed that my browser was trying to reach an agilebits.com address (I am assuming it was https://agilebits.com/browsers/auth.html, but I did not take a very close look). Even before noticing that my browser was trying to reach agilebits.com, but instead paying attention to a generic error that presented itself in the browser's main display area about not being able to reach the intended web site, I figured I was running into the typical sort of captive network problems that too often manifest themselves in these little coffee houses when trying to get in the Internet -- and so I immediately launched into running through my usual battery of hacks, including disabling/re-enabling Wi-Fi and trying again, removing the network name from the list of known networks before launching the browser, etc. None of those hacks worked this morning, though, and that's when I actually noticed that the browser was trying to reach agilebits.com. Having seen it so many times now, I assumed that the browser extension was trying to get authenticated vis-a-vis the request to have the user confirm that its six digits were the same as those rendered in the web browser's main portal. Because I had not yet successfully authenticated the captive network's login screen, however, and wasn't, therefore, allowed to reach the Internet, there was no way that an agilebits.com address was ever going to be resolved. So I then tried to disable the browser's extension and try again. That did not seem to change anything; the browser was still trying to reach an agilebits.com address. So I then uninstalled the extension, which allowed me, finally, to get to the network's login screen, and get on the Internet.
I don't recall this sort of thing ever happening before, but it could be that it was never the case that a new version of 1Password's browser extension was pending authentication at the exact same time as I was trying to authenticate with one of these captive network screens.
immediately after getting on-line, I downloaded and installed 1Password's beta version of the Safari browser extension, and so I was immediately forced to authenticate (err, confirm) that the same six digits displayed in the helper app were the same as those being rendered in the browser portal. From your list of available downloads (https://app-updates.agilebits.com/product_history/OPX4), I can see that the latest beta version of the browser extension for Safari -- and I presume that's the same version that's used for Safari Technology Preview -- (v 4.7.4) was released on 20 Feb, but I am certain that I have used Safari Technology Preview on this machine on that day and every day since, and I always install 1Password app updates very soon after they announce themselves and the browser's preferences panel for extensions is set to auto-update, so I would be surprised if it took as long as 3 or 3.5 days for the browser plug-in to get updated on its own. Unfortunately, I did not take note of which version of the browser extension was installed when I decided to manually uninstall it, but I can say that, before this morning, it's been 'a while' since I have been asked to authenticate the extension.
If I am correct that your authentication process is what was stopping me from getting to the local network's authentication/login page, I would urge you to look into this kind of conflict and find a way, if possible, to use the resources of the application itself to announce the fact that you can't reach the the necessary server in order to authenticate and allow the user to put off that process for a minute or two, if they wish to accept the risk of doing so. If in fact, that were possible, it could have allowed me to have a much, much less frustrating (and far, far quicker) time of getting through those local log-on sequences.
In case it matters, I'm running Safari Technology Preview Release version 50 (Safari 11.2, WebKit 13606.1.5) on macOS 10.13.4 Beta (17E150g).
1Password Version: 6.8.7 (687006)
Extension Version: 4.6.12 and 4.7.0b4
OS Version: 10.13.4 Beta (17E150g)
Sync Type: Dropbox
Comments
-
@cwisniewski: I hope you'll forgive me, but I got a bit lost along the way in your comments. I'll try to address what I think are the core questions here, but don't hesitate to correct me if I've misinterpreted anything.
Does the 1Password extension interfere with Wi-Fi captive portal?
No. The extension has nothing to do with this, and 1Password's authorization also doesn't happen over the internet; we're just using a premed webpage to trigger it locally and offer a guide (which does require internet) once it's setup.
The problem is the webpage. But it isn't specific to 1Password. Captive portal tries to redirect to the hotspot's login page or whatever, but this doesn't work over HTTPS (http://cnn.com is an easy to remember way to work around that though)...and as you can imagine we're pretty strict about enforcing that. It happens to me all the time completely separate from 1Password, and some browsers and hotspots (and OSes) don't recover from this well as you've noted.
Why didn't the Safari extension autoupdate?
This is only possible using the Safari Extension Gallery version, and betas are not allowed there.
I hope this helps, but again, let me know if you need anything else. :)
0
