I’m having trouble logging in to Local after updating to 9.1.1. Haven’t had time to test if it’s Local 9.1.1, Safari 18.2 or something else. I can manually change the url localhost:49003/callback to https to login. I’m running macOS.
Hey @emmtre! I just upgraded to 9.1.1 and tested this in Chrome and Safari but didn’t hit any problems. Maybe a full reboot could clear things up? You can also click on Preferences in the profile icon drop down to change your default browser and see if it works with an alternative.
@Nick-B Which version of Safari are you using? I didn’t have any problems with Safari 18.1 before updating both Local and Safari. But I might have changed the non-secure site connections setting in Safari. See below.
@Nick-B I tracked down the login problem to this Safari setting.
1 Like
@Nick-B Local should call the https version of the url localhost:49003/callback and not the http version.
Thanks @emmtre! Looks like I’m still on Safari 18.1. I’ll share this with the team for a deeper look.
1 Like
Thanks for reaching out @emmtre . I don’t have Safari 18.2 yet, so didn’t quite replicate, but I’ve added a ticket for us to offer someone as tribute to the Safari upgrade gods take a closer look.
My guess is that it won’t be a simple change to https because we’d need to generate a self-signed cert to use on those callback ports. But either way, we’ll take a closer look and see what we find!
3 Likes
I just updated to the latest developer beta and got a slightly different error message now so it could probably be Safari 18.2 causing it.
I’m having a little trouble installing Safari 18.1 again but what happens when you enable the setting to warn for non-secure connections?
You get an error message both before and after accessing the secure page hub.localwp.com during the login and authorizing process.
Thanks for this report, @emmtre. I don’t see the “non-secure site connections” checkbox in Safari 18.1 (macOS 15.1.1) or 18.2 (latest developer preview), can’t find mention of it anywhere online, and can’t reproduce this so far.
Is this something that was enabled with an extension or feature flag? It seems over-zealous for it to include localhost connections too since browsers generally consider localhost to be a secure origin.
I would not expect browsers to warn about insecure connections to localhost by default. In this case all traffic to the callback happens locally so threats such as MiTM attacks aren’t a concern. Local could add certs for localhost as Ben mentions, but this adds complexity and another point of failure that should not be needed.
Good reasons you might want TLS on localhost are for development parity with production or staging, when using features that enforce TLS (like Service Workers), or when testing security headers/cookies that need TLS to function. But those don’t seem to apply in this case.
1 Like
Many thanks for your thoughts. It was very interesting and strange that you are missing the non-secure site connections setting.
If I remember correctly i first saw this setting in one of the 18.2 beta releases. I also think the Safari developer beta, public beta and technology preview might differ and is based on different versions of WebKit.
The Safari defaults domain key is UseHTTPSOnly for this setting but there is no information to be found anywhere as you also discovered. And I don’t see any special feature flag that would activate this setting.
And the Safari help page is also missing any information about this non-secure site connections setting.
Can it be a cached HSTS (HTTP Strict Transport Security) policy for localhost somewhere in the system for another app that is causing the login problem to the Local account via localhost?
defaults read -app Safari UseHTTPSOnly
1
Safari 18.2 Beta Release Notes
Security
New Features
- Added a warning when connecting to a website over an insecure connection. (99348736)
- Added support for automatic fallback to HTTP if an HTTPS connection or request fails. (114286729)
- Changed to prefer HTTPS navigations by default. (133799554)
1 Like
Good to know there are others who have also encountered this problem with Safari.
