Logging in to wifi network no longer works

1pw__user

1Password 5.2.1
iOS 8.2
iPhone 6 and iPad2

I frequently need to join a wifi network provided by Aruba Networks. My iDevices are set to automatically join this network. If I attempt web or email access, I am prompted with a user/password login webpage, much as you would see at a hotel, etc. Once I log in I remain part of the network until leave the building for >1 hr, after which I am again prompted to log in.

Previously, I could launch 1Password, click the login item I had created for this network, click the web address (didn't matter what it was because all roads led to the login page), and 1Password would automatically populate the user/pw and log me in.

Beginning several months ago it no longer works. Any network access via Safari, email, etc brings the login page. In 1Password, however, if I use e.g. google.com to stimulate the login page, 1Password goes out over the cellular network to retrieve the page, bypassing the wifi login. If I use securelogin.arubanetworks.com (an address I copied from Safari's address bar and not accessible from the WAN), I get a permanently blank screen. If I disable cellular data and try to fetch e.g. google.com it times out. I have tried instead manually using 1Password's built-in browser but the results are the same, regardless of which user agent I select. I have tried clearing web data but the problem persists.

Unfortunately I cannot correlate a particular version change of 1Password or iOS with the change in behavior. Nor can I rule out that something has changed on the wifi network. However it continues to behave as it always has in every app but 1Password.

I see the same problem on both the iPhone and the iPad.

This is a very frustrating problem (my user name and password are long and I am not able to change them -- typing them in is painful), and this problem significantly reduces the usefulness of 1Password for me.

Any help is appreciated!

MrC

Hi @1pw_user,

You're describing what is called a Captive Portal. The network is available, but all access to remote sites is being shunted to a single authorization web page where you provide credentials. Your devices cannot get full network access until you've provided those credentials (the network devices on the LAN configure themselves to allow access to your individual device).

I wouldn't expect this is a 1Password issue.

Try using 1Password for IOS's extension to enter the data when you get to that credentials page. You'll need to have the web URL as one of the Website fields in the Login entry.

1pw__user

Yes, that's it exactly. As I said, it worked until fairly recently. I've tried the extension but when I'm presented with the authorization page, I am not given the "share" button that would allow me to access the extension.

Thanks!

MrC

I'm guessing that your captive portal page was updated, and is loading a non-Safari login mechanism? Is it Safari you see opening when you try to connect?

1pw__user

I'm logged in right now so I will have to log out and let my session time out before I can look to see. Will update here with details. But surely all the server is doing is serving a web page, yes? It shouldn't be able to control what app displays that page on a device (and this is a heterogeneous device environment -- I just happen to be using iOS. Other folks use Android, etc...)

Thanks!

MrC

Protocols can be registered with a system to open other apps redirected from a webpage. For example, when I click on an iTunes link in my email, a web page is opened, and that webpage then redirects to open in iTunes. And webpages know what browser and OS you are coming from (this info is in the HTTP header information).

1pw__user

I would think for interoperability the server would be configured to be as device/OS/browser agnostic as possible. Special cases are evil. ;-)

1pw__user

Here's a screen grab. Not sure if Safari is rendering this or something else. I still don't understand why previously 1Password would try to connect over wifi and stimulate this screen whereas now it immediately goes out over cellular data and bypasses wifi, whereas mail, browsing etc go to wifi first.

Ben

iOS and OS X both have detection of captive portal logins and display the screen you see there (or similar on OS X). While on the back-end it may be Safari doing the rendering, Safari is not the UI that is used, and it doesn't appear Apple offers the ability to integrate Safari extensions into this view.

Basically it seems Apple is checking for internet connectivity, and if they get back a response that looks like a captive portal they require a login through their special captive portal UI. If you do not login through that the device assumes there is no internet connectivity on that interface, and will fall back to the next available interface that does have internet connectivity (in the case of iOS this is likely the LTE connection).

At the end of the day this appears to be more of an iOS/Mac issue that we'll need to bring to Apple's attention, but I will mention it to our developers so that they can attempt to make that contact.

Thanks!

1pw__user

Thanks! I wish I could tell you specifically when it stopped working, but I can't recall. But the fact that it DID work was what convinced me to buy the full version of the app.

1pw__user

Is it possible to roll back to a prior version to test? I recall it worked after 1PW was given touch-id integration, so sometime in the 5.x stream. I'd like to try 5.0.1 and see.

Ben

@1pw_user,

Apple does not allow new downloads of older versions (unless the old version is the latest your device can run). If you have an older version saved in iTunes though you can possibly install it from there.

I'm not really sure how this ever would have worked though, unless at some point Apple changed the way iOS handles captive portals.

MrC

It is likely that the captive portal itself changed in a way that now forces the use of the login UI. There is a "Bypass Apple Captive Network Assistant" setting in the Aruba software. See:

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Apple-iOS-Wispr-and-Captive-Portal/td-p/159438

Ben

Interesting! It sounds like, contrary to the advice offered in that post, you want to enable the bypass setting to achieve what you're looking for @1pw_user.

1pw__user

@bwoodruff -- thanks. I'll have a stroll through my time capsule and see what I have.

@MrC -- not sure what to say. I think the "force login UI" switch is and has been turned on. I automatically get the login UI whenever I 1) open a browser (Safari, Mercury, -- but not 1Browser), 2) open Mail app, or 3) select "visitor wifi" in "Settings->Wi-Fi". There may be other scenarios as well but those are the three I most often encounter.

In any case, should I expect to see the login UI when launch and/or attempt to browse in 1Browser? Currently 1Browser goes over cell data (if it is turned on) or fails to connect (if cell data is turned off). It does not attempt to connect over wifi until /after/ I have authenticated manually in the login UI.

1pw__user

s/turned on/turned off/g

Ben

@1pw__user,

It looks like you may have been composing your reply while I was posting mine. Please see my post just above yours:

https://discussions.agilebits.com/discussion/comment/192299/#Comment_192299

1pw__user

Unfortunately the configuration of the portal is beyond my control. But again, should I expect to see the login UI when launch and/or attempt to browse in 1Browser? Or is there a technical reason it behaves differently from the other browsers I've tried?

Thanks!

MrC

This intrigued me:

regardless of which user agent I select

Are you changing the User Agent in Settings? If so, that's not likely to have an impact, as it is probably only affecting a certain HTTP header being sent.

Or are you long-holding the website URL in the Login entry and selecting Open in Safari?

1pw__user

Changing user agent in 1PW settings. I didn't expect it to make a difference but it was a knob I could turn so I tried it (and having tried it, mentioned it, in the interest of completeness....)

I had not thought of trying long-holding and selecting open in safari. So I tried it. If right now I try to open the URL in 1Browser I get a blank screen (this on the ipad without cell data). If instead I long-hold and open in Safari, I get switched to Safari and see the login UI.

Thanks!

ag_kevin

Glad to hear it is working!

1pw__user

Nope, not working. Still doesn't log me in. :-(

ag_kevin

Hi @1pw__user ,

Sorry about that, I misread your last post. It appears to be the captive login. iOS is basically grabbing the login page and presenting it in a view that doesn't allow extensions. There's not much that we can do to prevent that, and I'm not aware of a setting in iOS to exclude this site from that feature. I don't believe there have been any changes in 1Password that would change it. It's likely that arubanetworks.com (or an iOS update) changed something so iOS detects it now.

We will investigate this issue and see if something can be done, but honestly, I'm a bit skeptical that it'll be possible to change something on our end. In the meantime I suggest when you get to one of these network locations, instead of using a login, copy the arubanetworks.com password before trying to go to a web site, so that you can at least paste the password when the screen comes up.

1pw__user

Sorry -- I can see how it could have been misread.

I found a copy of 1PW 5.0.1 in my Time Capsule and restored it to my iPad. It behaves the same as 5.2.1, so the change must have occurred in iOS or the portal settings, not 1PW/1Browser. And I stand corrected about other 3-party browsers stimulating the login UI -- Mercury does not. I was mistaken. Like 1Browser all I get is a notice that the network connection is offline & a blank page.

RE:copying and pasting the user/pw -- yes, we're back to that. That was what I was doing before I found 1PW, and I installed 1PW to avoid having to do that. C&P is less cumbersome than typing them in, but still cumbersome....

I'd be very happy if you can find a way to turn this former "bug" into an official feature. In "open in Safari," is there any way in the handoff mechanism to pass along the credentials and programatically populate the fields once Safari opens?

Thanks!

Ben

so the change must have occurred in iOS or the portal settings

I suspect the setting MrC linked to got turned on at some point.

In "open in Safari," is there any way in the handoff mechanism to pass along the credentials and programatically populate the fields once Safari opens?

There is not, unfortunately, and even if there were, the screen you are seeing for the captive portal isn't 'normal' Safari. If it were, we likely wouldn't have this issue, as Safari on iOS can use our extension now.