Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Most of his issues with magic links don't exist everywhere. Maybe "Notion's" magic links are bad, but not everyone does that.

They're not tedious if you persist the login beyond 1 session.

There's also no need for any type of codes. You just receive the email, open it, click the link and then you could be potentially logged in for months or longer (it's up to the site who issues the link).

It's one of the easiest and fastest flows you can ask for with technology that works today in all major browsers.



> You just receive the email, open it, click the link and then you could be potentially logged in for months

One caveat is that your ios gmail app opens an internal browser, that has distinct cookies from main one. So there needs to be some clever websocket listener on the "main" browser that would receive a signal that a person signed in.

That said, the product I'm building needs users to log in rarely and painlessly, I decided to do:

1. use simple magic code (no magic link, also "please fill your full account info" once logged in, eliminates separate registration)

2. use "sign-in via ..."


How long should the link work for though? What are the security implications?

Also, you get cases where someone has email checking set up on their phone but not the machine they're on so clicking the magic link isn't ideal. This can be helped by supplying a code in the email you can type into the site though.

As a side note, how do developers working on systems that need magic links deal with them while developing? Usually you need some way to bypass the email checking part while you develop.


> How long should the link work for though?

Up to you. An hour or 2 seems ok as a general rule.

> Also, you get cases where someone has email checking set up on their phone but not the machine they're on so clicking the magic link isn't ideal.

Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password confirmation links (as an alternative to magic links) would also expect you to click a link to verify your account, which means you would have to do it on the same machine you signed up with.

> As a side note, how do developers working on systems that need magic links deal with them while developing? Usually you need some way to bypass the email checking part while you develop.

Couple of options. Bypassing it is a valid choice. Also if your framework supports it, you can often configure things in development so that emails aren't really sent, but you're given a URL that you can visit which opens a web based inbox page. This way you can preview your emails and click links. It's basically an in-memory no-op local mail server for receiving email. Rails and Phoenix do this well.


> Up to you. An hour or 2 seems ok as a general rule.

Oh, I meant how long after you click the link should you stay logged in for? My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links.

> Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password confirmation links (as an alternative to magic links) would also expect you to click a link to verify your account, which means you would have to do it on the same machine you signed up with.

I haven't used magic links enough to be honest but when I sign up using dev/test email addresses I don't often check, the hassle to get the email is annoying. I guess that's true for account verification emails as well though, which is a good point.


> Oh, I meant how long after you click the link should you stay logged in for?

That's up to the service. I think for most use cases having the login last 3, 6 or even 12 months is ok and then it would get invalidated early if the user explicitly logs out, they change their email address or the server blacklists the token.

> My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links.

1 hour of inactivity is a very very long time for a bank. I think my bank logs me out after 15 minutes or so but I can't remember when that last happened.

Are you really idling for long periods of time on your bank's site? I typically login with a specific purpose. Maybe it's to check my balance, or see if a recent charge / deposit went through, etc.. It's things like that where I'm in and out in 30 seconds, or at most a few minutes.

In both the password and magic link case, you can still re-validate the session without any user intervention as long as they are actively using the site. If there was a legit use case where people's sessions needed to expire after 10-15 minutes of inactivity and it was very common for that session to expire I would re-think the entire user experience and design things so sessions expiring weren't so common because this sounds like a really poor user experience in any case. But if the 0.00001% use case came up where you wanted to torture your users with logging in every 10 minutes, then I would avoid magic links.


Magic link emails are terribly slooooow. Waiting for that email takes too long most of the time. I could've already logged in with a password by now, not even using a password manager.


> Magic link emails are terribly slooooow. Waiting for that email takes too long most of the time. I could've already logged in with a password by now, not even using a password manager.

That depends on how it's implemented.

It's up to the site owner to dictate the behavior.

You can have them login the first time without an email link click and let them know they need to confirm their email after closing this session in order to access the site. This way you can use the site immediately. That is no less secure than most password based sign ups that have no email confirmation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: