Somehow handle magic links with Gmail's in-app browser (or similar)

[wilg]

Extremely annoyingly, on iOS, the Gmail app by default opens all links in the in-app browser. That browser does not share sessions with Safari or the user's normal browser. That means they'll only get logged in within Gmail and it's a very confusing user experience.

You can see other developers struggling with this here: https://github.com/orgs/supabase/discussions/15708

This is actually worse with Devise's confirmable, because those links expire. This is one reason why it would be nice to fully replace confirmable with passwordless, as discussed a bit in #58.

The "best" way for the user to deal with this is to long-press the magic link and choose "Open Link" which will open it in the default browser. It's worth noting that this would not work if the link expired like in confirmable, because long-pressing the link to find that button also includes a preview of the URL, which opens the link and would expired.

The most obvious approach the user might try is to click the "Safari" button from the in-app browser to move their browsing session out of the email client. However, this doesn't work because the magic link has already logged them in and that button will take them to the current page in Safari.

Would appreciate any ideas here. One idea I had is that an interstitial page could be inserted that says something like "Log in with this browser" and then a button to load the actual magic link. Probably just a param like confirm=true added to the route. This way, the user could tap the link to open in Safari before they actually log in.

Also, because of all of this I really hope we can figure out a way to get passwordless working more smoothly with confirmable (#58) because confirmable is much worse with the expiring links and it would sort of suck to have to implement a workaround twice.

Would love to hear if anyone has solved this!

[iainbeeston]

This issue bothers me too. I don't have a solution for it, unfortunately. I think my preferred solution would be that if the user clicks the link anywhere, it signs in and redirects the user in the original window (where they filled in the sign-in form) as well. I think action cable or turbo streams might be needed for that though.

[abevoelker]

Yeah this is definitely something we should support better. Interstitial is probably the way to go as you said @wilg . As @iainbeeston pointed out action cable or turbo streams are probably the ideal for that. Although I would think you could fall back on simple polling as well

This was requested in #5 early on in the project. At that time I didn't want to overcomplicate things but now I think it's a flow that should be accommodated.

Another way lots of sites do it now is emailing you an n-digit numeric code you have to enter on the interstitial page. For example Shopify's "Shop" app (screenshot below) and PayPal. Ideally both methods should be supported

[wilg]

Yeah thinking about it more the 6 digit code probably makes the most sense and offers the fewest paths for user confusion. Not sure how that interacts with the clickable URL, but maybe you just don't need the URL if you do it that way, that might be simplest?

[abevoelker]

(Copying and pasting this to all open issues/PRs:)

Hey all, per #64 I unfortunately won't have much time for the foreseeable future to maintain devise-passwordless to fix the open bugs and work on new features. I'm not abandoning this project, but due to some life issues it's just at the bottom of my priority list for now.

Anyone who wants to step up and be a maintainer to shepherd the project forward would be welcomed! I just ask that you've opened a PR, or written an issue, or can otherwise demonstrate some familiarity/competence with the project. You can reply to #64 or message me privately (through email or socials since GitHub doesn't have DMs) if interested. Thank you ✌️