Unable to login on Safari

[SarahSibert]

Description
Unable to log in on Mac Safari and iPad Safari.

To Reproduce
On Mac and iPad Safari when I navigate to the opendor.me URL and click ‘sign-in’, the page appears to start to redirect to GitHub but does not complete and instead the OpenDor home page just refreshes. If I try to sign in on other pages e.g. Sponsors the same happens and the page just goes back to the home page.

[bhushan]

the bug is confirmed..

[Gummibeer]

Can anyone prove a screen recording including persisted network tab open? 🤔
I will try it myself today. I'm really interested in what safari does that time ... 🤯😅

[SarahSibert]

I cleared my cache etc. and then retried, the first time it went as far as the GitHub authentication. I logged in but it just went back to the home page. After that I tried to log in again and it was as before. See the attached.

OpenDorLogin.mov

Not sure if you need anything else.

[Gummibeer]

Okay, I was able to verify that bug on my local Safari.
But there's not a single exception - so I really wonder what happens. 🤔
Will see if I can reproduce it with my local environment as well to easier debug.

[Gummibeer]

After playing around a bit it seems like the current user.id session value gets lost during redirect, if I return a view from \App\Http\Controllers\Auth\GithubController::__invoke() everything works just fine.
But that isn't a solution. I assume that it's somehow related to a cookie or similar that isn't transferred/persisted in Safari during a redirect. 🤔

[poldixd]

Same on iPhone Xs (iOS 14.4.2)

IMG_0447.MP4

[Gummibeer]

Thanks @poldixd . I still don't have a real idea why Safari can influence values in my serverside redis session store. 🤔
But I assume that it's a cookie that should have to be renewed and isn't because of the redirect - as soon I render a view the user gets authenticated like expected.

A possible solution I could imagine would be to render a view that redirects to the wanted page client side. Like the Laravel fallback one.
If I've pined the problem correctly that should solve the issue.

[Gummibeer]

Rant incoming 🤬

Go home Apple and put Safari in the trash! 🤯

The last idea really works ...

return redirect()->intended(
    route('home')
)->setStatusCode(200);

Defining 200 status code means that the symfony client-side HTML redirect is returned and rendered and whyever safari is now fine to accept the cookie ... 🙄🔫

I will push and deploy that change in some minutes so you all can check if it really fixed it.

[Gummibeer]

Okay, that doesn't work on production ... 🤯
Even in a private tab it doesn't work - so also no odd caching issue.

[Gummibeer]

Okay, the last commit fixed it - at least for me.
Can you please verify it with your device(s)? 🙂
You will now see that redirecting to ... screen for 2 seconds - but everything faster also hasn't worked ... 🤯

[SarahSibert]

OK so it now works on my iPhone and iPad. Not tried the Mac yet.

[poldixd]

Yes, I can confirm. It works on iPad Safari and iPhone Safari. Perfect!

[bhushan]

fixed on MacBook safari too

[mallardduck]

I wonder if this is all related to the cookie settings described here: zotonic/zotonic#902
Which is funny since it really seems the same -has the same fix at the very least- and in theory should be resolved: https://bugs.webkit.org/show_bug.cgi?id=139683

[Gummibeer]

Seems like the reason - but as I can't enforce a setting in Safari for all users this still seems like the only way. 😟
As others got to the same solution I think that this is the way to go, possibly fine-tuning using JS instead of http-equiv to get a faster redirect. 🤔
But for the moment it works and the 2secs are acceptable, I think.

[mallardduck]

@Gummibeer - absolutely agreed that the current solution is reasonable and that JS may provide some benefits. still this issue has piqued my curiosity tho, so i'm going to be poking around at it a bit.

as we've discussed I don't have access to Nova, so I wasn't able to run the full site. yet, with some clever hacking around stuff I've got a local dev version of the project working now. so at the very least I can poke at the Oauth issues safari is causing.

---

UPDATE: It appears to be something related to SSLs as my local dev starts breaking after applying an SSL. While it works in Firefox still it does not work in Safari now. I think that's a good sign for chances of replicating it in a way to debug it.

[mallardduck]

OHHHHHHHHH BOY. Is this an interesting discovery I have here and I wish I had an explanation - @Gummibeer.

However from what I can tell it appears that the serviceworker (when run in safari) is what is eating the requests and cookies. I came about this as the cause by noticing two main clues here.

The first being that the "Transfer Size" was listed as (service worker and the second that the "Source" listed in the Summary by Safari was showing as Service Worker instead of Network.

So with that in mind, I nuked my Safari cache and removed lines 2-14 of web.blade.php and I found that Safari logins work just fine.

---

See here for working examples where ServiceWorker was disabled:

---

I also have an HAR file exported that I could share to you as well if that helps.

[Gummibeer]

Yes, I've noticed also a different behavior between http://127.0.0.1/http://localhost and the production domain. So I assume that valet or expose could help in that case as they provide real SSL domains for the local environment.
That's why I've stopped for the moment to finetune the delay or play around with JS as I would have to add one of the tools to thee eenv and it works for the moment.

[Gummibeer]

Okay, that's super strange as I explicitly apply the NetworkFirst strategy to prevent any issues as long as you have internet. That Safari handles that differently is more than annoying ... 🤯
To be honest I'm absolutely no experience with ServiceWorkers - but why the view solved it could be that the /auth/... paths are excluded from service worker.

[mallardduck]

Steps to Replicate

1. Setup local opendor dev area with Valet
2. Setup proper .env file with GitHub oauth secrets and such
3. Fight around Nova by mostly disabling it (not required if you have Nova access)
4. Use the valet secure command to get an SSL.
5. Disable the workaround that's in place and return using:

        $redirectTo = url(session()->pull('url.intended', route('home')));
        return response()->redirectTo($redirectTo);

6. The Oauth login should now be broken.

Steps to test my theory that service worker is making Safari sad:

1. Nuke browser caches.
2. Clear view caches via artisan.
3. remove lines 2-14 of web.blade.php
4. GitHub oauth logins should work again now.

[mallardduck]

So from what I've found it also seems that the service worker only loads when doing a prod build. So when I was just testing with npm build dev the issue doesn't happen at all. Meaning to test the underlying service worker issue I think only prod asset builds will work for testing.

[mallardduck]

@Gummibeer - you know what I think the issue might be a combination of two things. Safari treats the consecutive redirects as part of the same "request action" (for lack of better term) and that the final redirect is actually ending up on the home page /. Which the service worker is attempting to cache.

--

Actually now I'm very confident this is the issue.
Going to see if I can send a PR that can help solve this.