Hacker News Reader

Comment by zeroxfe | Hacker News Reader

I sidestepped a whole bunch of user/password management/verification complexity by restricting my toy app (https://pitchy.ninja) to "login via email" where you get sent a code anytime you need to log in.

I wasn't sure about how well it would work when I first launched it, but now, about a year and a half later, I'm really happy with it.

The biggest advantages are: I'm not tied to an SSO provider, I don't have deal with password management/security/reset/etc., and I have a super simple UX (identical flows for signup and login.)

View on HN

It'd be prudent to have an option of a backup email address, in case the primary one on file dies or becomes unavailable.

This is only possible if you store client state, like the primary email address.

I use the same approach to the above, where users authenticate with an email address. I don't store any client state on the server though which is nice for regulations like GDPR.

I have 'logged in' users without storing a single piece of data about them! No tracking nor performance stats on the site either.

What's the point of having them log in in the first place then?

Spam prevention and rate-limiting

I do the exact same thing for all of my new applications. Magic Link Auth is 10x easier then trying to store passwords. The added benefit for the user is they don't have to remember any more passwords besides their email password. Which is already used as a source of truth.

I'm doing the same, but using Auth0 for the login-by-email. I don't think it'll really tie me to anything since it would be trivial to change to another service.

What did you use to implement yours?

I got an SMTP gateway from AWS: https://aws.amazon.com/ses/

This is a great option for UX. Here's a fun old post from 2008 (from a former co-worker) on a similar topic: https://almaer.com/blog/its-just-my-email-password

You do want to make sure you add enhanced security around changing an account's email address (make them log in again, for example). The analog is forcing people to re-enter their password when changing their password in a more typical username/password system.

A good percentage of our outbound emails end up in Spam folders, Promotion inboxes, or heavily delayed. It might be simple to implement send a login link via email and convenient for those when it works, but when it doesn't, it doesn't. So the best is to have traditional passwords and an optional "send me a login link". If they get one of those two working, then great. But you still have to deal with password management / security / reset / etc. Nothing is trouble free.

Don't you want to validate a new users email address before you activate their account anyway?

When the email is not received in the customer inbox, you have a bit of a loop where the customer has a valid email but is not receiving the communication.

Give the majority of people have working email, how about the other way?

Default "login by email", with optional "set up password" link for those who have problematic communications.

The two big issues with this approach is that emails can be significantly delayed sometimes, and/or can end up in the spam folder.

If you can reliably avoid these two, you're golden.

Nice. I see potential problems, but nothing that would stop me using the idea for a personal project until it grew into something else (at which point I move to something else, and if it never gets to that point I've lost nothing but gained time I'd have spent implementing something else).

FYI, in Firefox, hitting the back button does not take me back from your app.

My annoyance about this approach is that it forces me to open a cookie exception to your app, or to get a new magic link each time.

That shouldn't be an issue unless you block session level same-server cookies, which is a bit OTT.

Or it is implemented with longer lived cookies and you block everything that won't expire with your current session.

(or you don't mean that you are blocking cookies but instead that the site is requesting you allow “strictly necessary cookies”, in which case the site is being overly cautious, no regulation requires requesting consent for a strictly necessary stored value and a value tracking a login session fits into any reasonable definition of that)

The concern I'd have with “login via email” implemented this way is that it could be faf to support if your sending mail server gets unexpectedly added to a blacklist somewhere so the messages stop getting through to a bunch of your users. That said, for a personal project I'd guess the risk is low if you are hosting on a reasonably good provider, don't have competitors who'd DoS you by making your service send out login tokens to a pile of random addresses. And even if it does become a problem it won't be an earth-shattering one for a toy project. I may have to try it in a future plaything.

As someone who lives in private browsing mode only, and stores no history ever... yeah. This is a service I wouldn't use.

Developer convenience over user experience, is great, until you realise your users are crazy.

> This is a service I wouldn't use.

As a toy project, you probably wouldn't even know about it.

And if you did, sometimes sending some users off disappointed on such a matter is a small price to pay for being able to quickly get on with other things. Supporting people who block even session cookies is like supporting people who use IE or an ancient Android browser - ideally you'd like to support everyone but getting 100% there is too much work that it would consume too much effort that would be more useful elsewhere.

If the issue is blocking session level cookies, then there are many many more services that such users have trouble with. There are other methods (adding session tokens in all URLs and form submissions instead of, or as a fallback for, the cookie value) but that is work to do and maintain, and adds its own issues to the mix.

> Developer convenience over user experience,

I'm not sure it is a hit to user experience, at least not a significant one for the vast majority. The login is a bit more faf than normal as you need to wait for, read, and action an email, but once logged in all is normal and there is the benefit of not needing to manage another user account's credentials.

SMTP isn't something I feel should be trusted as the key for an SSO system for important credentials, but again: we are talking toy/experimental/personal/PoC projects here.

> is great, until you realise your users are crazy.

Well, yes. To be honest, fending off a few crazies would be a benefit most project large or small ;-)

Why would email instead of user/pass/oauth require you to change your cookie settings?

Reply on news.ycombinator.com