Authentication flow doesn't work with Safari

[shsteimer]

Description When running aem up with an authenticated site the auth flow never successfully completes if your default browser is safari. When clicking send on the prompt page, an error occurs which is only surfaced via the dev console.

To Reproduce Steps to reproduce the behavior:

1. make safari your default browser (my setup: safari 18.3 on Mac OS 15.3.1)
2. run aem up for an authenticated site with no stored site token
3. login with the IdP
4. when you arrive at https://admin.hlx.page/auth/adobe/ack?code=... click send
5. note that nothing happens
6. open dev tools console and note the error

Expected behavior The auth flow should complete successfully. If that isn't possible due to some safari specific restriction, the user should see a message with some info on what they can do to work around.

Screenshots

errors from console:

[Warning] [blocked] The page at https://admin.hlx.page/auth/adobe/ack?code=.... requested insecure content from http://localhost:3000/.aem/cli/login/ack. This content was blocked and must (ack, line 7)

[Error] Not allowed to request resource
	(anonymous function) (ack:7)
	sendPost (ack:6)
	(anonymous function) (ack:23)
[Error] Fetch API cannot load http://localhost:3000/.aem/cli/login/ack due to access control checks.
	(anonymous function) (ack:7)
	sendPost (ack:6)
	(anonymous function) (ack:23)
[Error] Unhandled Promise Rejection: TypeError: Load failed
	(anonymous function) (ack:7)

Version:

ssteimer@Seans-M3-Macbook-Pro ups % aem --version
16.10.1

[andreituicu]

It looks like Safari is the only browser that very strictly enforces not making http calls from a secure https connection, even on localhost. The other browsers treat localhost like a secure https connection.

https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content#loading_locally_delivered_mixed-resources https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content#browser_compatibility

Will probably need to switch the response from Helix Admin to transfer information via a redirect to localhost (assuming that's supported by Safari, will need to check). But that has different security disadvantages, unless we use something like PKCE, which requires more effort to implement. Will need to check what we can do...

[shsteimer]

@andreituicu While obviously we should strive to support all major browsers, I think it would be sufficient, or at least a good stop gap, to detect the user agent is using safari, and ask them to use a different browser to authenticate

[andreituicu]

@shsteimer please see https://github.com/adobe/helix-cli/pull/2500 implementing your stop gap suggestion.

[alexkli]

FWIW I came across this, two comments that might help:

1. Setting cookies in Safari for http://localhost works if you leave out the Secure; flag on the cookie.
   • I ran into the same for an authentication I built and I simply special case if it's http://localhost and am not setting Secure; on Set-Cookie for those.
   • On production with HTTPS I ensure Secure; is always set.
   • But it depends on the value for SameSite:
     • SameSite=Lax: you can always leave out the Secure; (on http://localhost)
     • SameSite=None: at least Chrome enforces Secure; to go with it. So I only leave out the Secure; if it's localhost AND user agent does not include Chrome
   • Otherwise both Chrome and Firefox seem to happily ignore Secure on http://localhost as you noticed.
2. aem up has a bug where it is not passing cookies through, especially multiple Set-Cookie headers get broken. See #2578

[andreituicu]

@alexkli in this particular case, it is not a cookie problem. The aem-cli doesn't use cookies to authenticate to the site. The problem is that this fetch request originates from a site served over https (admin.hlx.page) and goes to a site served on http (localhost), Safari doesn't like that. Chrome and Mozilla consider this safe and treat localhost as a safe site, even when http is used, while Safari is the only one that treats localhost like any other site on the internet served over http and blocks the request.

[alexkli]

It uses cookies like the hlx-auth-token, no? If yes then it might be the way that cookie is set by admin.hlx.page and with the right cookie setting especially SameSite it should be doable. In my case I could make it work on OAuth redirects between localhost and Microsoft Entra (https://login.microsoftonline.com). Just a thought.

If not the only other issue for cross-site scenarios would typically be CORS.