open in SQRL -> cancel causes stuck on localhost

[Gristle]

Hi,

When you click the login button, iOS asks if you want to open in the SQRL app. If you say cancel, the browser is stuck on trying to load localhost:25519. This doesn't seem like a problem with Jeff's app, but simply a problem with choosing how to initiate the localhost connection. Seems it should wait until the user has confirmed they want to open in the app, otherwise cancel leaves the user in a very confusing state.


Any ideas here?

 

[Gristle]

thinking this through, this might just be inherent with how safari in iOS works. If there is not a fix, I guess it's not a big deal, but it's still confusing nonetheless.

 

[Hzy]

I have noticed the same. I agree this seems like iOS behavior related to the use of custom URL ( SQRL://www...). I have no idea if this is what should be happening or not, but it seems reasonable given the URL is triggering a local app. I noticed that even if you don't cancel after clicking the QR, if you just change back to the browser, it is sitting at local host, which I think is just where it has to wait for the response from the app (?). I mostly noticed this when testing entering an incorrect ID pwd, or as you said, canceling the login. I think most users would connect that they canceled or didn't complete the login in time ...did something else instead...then, either close the tab, or hit a back button, not think to much about it, and retry if they still want to. Not sure what we can do if that's how it's going to work. Ideally, this might be noted as expected behavior in some kind of user guide / FAQ...assuming it is determined that this is expected and of course correct.

 

[PHolder]

One would expect the app to work no matter how it's used... but there are two immediate possibilities that come to mind. One is that Jeff's app hasn't implemented the localhost functionality at all. The attempt to connect to it is from the Javascript on the web page. I was under the impression it was supposed to detect if it saw the connection on port 25519 or not and act accordingly, but it may be getting fooled by iOS some how. The other possibility is that it should be working right, and iOS is messing with it in some way. iOS likely has a different sort of security firewall for inter-app communications...

 

[Gristle]

Well for the case I'm talking about, Jeff's app hasn't even been invoked yet. If safari asks to open in an app, and you say "cancel," then the app is never launched. Seems the JavaScript on the site needs to know whether the handoff actually occurred (meaning the user said yes, proceed to launch the app), or whether the use clicked cancel. In this case, clicking cancel still causes the JavaScript to initiate a connected to localhost:25519 which never connects, so the page must manually be aborted. I'm pretty sure this needs to be addressed at the server side, not the client side.

 

[Gristle]

Or we could simply call this expected behavior and move on. Just seems that leaving a dangling connection might confuse users, or give the sense that something isn't working right. An uninitiated user might just sit there waiting for a long time expecting something to happen. Ideally an error would pop up or the connection would simply abort and the page would refresh.

 

[Jeffa]

if the OS prompt is denied I should not ever know about the call the the URL scheme.

My understanding is that the javascript on the login page probes the localhost web server to make sure it is there before it attempts to navigate though.

So I am confused why in the case of a cancel the browser is still trying to navigate.

 

[Gristle]

I think it's just an order of operations problem. The JavaScript is probing localhost before the user selects whether to use SQRL or cancel. If they cancel, the probe should either be aborted, or not triggered in the first place.