The standalone SQRL client is fully proxy aware. During development we had at least one user whose enterprise was proxied. So I added proxy awareness and we confirmed that all was well. What
@mdh42 is describing is more than a simple proxy. It's a blocking UTM device as demonstrated by the fact that informing it of the client's User Agent allowed it to function.
Steve,
I know this is an old topic but I'm currently sat behind two enterprise proxies (as in, a choice of two to get onto the Internet). It appears SQRL isn't "fully proxy aware", or at the very least, I'd be interested to know which RFC's you're talking about above?
We use two proxy systems: Bluecoat for one, Microsoft Threat Management Gateway for the other (legacy) one. If defined manually on a Win 10 1903 laptop I'm sat at now (having logged in with Jeff's client - a nod there to his work) I see the screen below when trying to login to
https://sqrl.grc.com/demo using your Windows client using either proxy. This is also the case when using a pac file that passes back a particular proxy depending on the destination URL being requested (mainly for Office 365 support which bypasses the proxy and heads straight out of the firewall). In all other respects I can browse around grc.com and the forums without issue. Not sure if this is important but this machine isn't domain joined
I'm more than happy to assist with troubleshooting (network trace) if you can guide me as to how the communications are supposed to look from the proxy perspective. Our proxies are authenticating and are otherwise working with cached credentials. I feel to have this adopted in the enterprise would be the icing on the cake, and to that end perhaps a way to force SQRL to surface the proxy asking for credentials might be worth considering, so the Windows Credential cache can then take care of them.
Sorry if this is a spanner in the works, looking forward to release... and SR6.x / SR7
Thanks for all the great work
--
Mark
