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 did you use to implement yours?

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.

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

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

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.

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

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 ;-)