[joshstrange]

> > Do you not have to enter email on register?

> Yes, I have omitted this from both workflows.

You specifically complained about having to enter your email on the magic link flow:

> 1. My email address never auto-fills so I need to click the field and select the completion suggestion. This is even worse if I am using a per-site email address.

> > is a magic link really so difficult to use twice a year?

> No, but it is still more difficult than a password multiple times a year. Neither of these have a yearly cost so it doesn't really matter how often you do them. I wouldn't use "only twice a year" to justify that people can come to our office in person to authenticate over a magic link.

Yearly costs to who? The user? I guess there isn't really a cost to them other than storing/keeping the password but there is absolutely a cost to the developer and I'm not talking about the cost of storing a hashed/salted password in the DB itself. There is a cost to build and maintain a password-based system. It means implementing and maintaining a number of things like your salt, password complexity requirements, password reset flow, and more like you going to use something like HaveIBeenPwned's hash list to make sure people aren't using known passwords?

Passwords are not zero-cost and have ongoing concerns. I'm not saying magic links are always or even often the best choice, just that they do have a perfectly valid use-case.

[DocTomoe]

> but there is absolutely a cost to the developer and I'm not talking about the cost of storing a hashed/salted password in the DB itself. There is a cost to build and maintain a password-based system.

Seriously ... if today's developers are unable or unwilling to learn about basic hashing/salting and database storage/value comparison, and consider such concepts 'costly' ... we may have passed the zenith of technological advancement, and are in a 'downfall of the Roman Empire' phase. Have some pride in your work.

> It means implementing and maintaining a number of things like your salt, password complexity requirements, password reset flow, and more like you going to use something like HaveIBeenPwned's hash list to make sure people aren't using known passwords?

Do you reinvent the wheel whenever you need to drive somewhere? these things mostly are already baked into most frameworks, and if they are not, most developers build something like this once, and reuse.

> [Magic Links] they do have a perfectly valid use-case.

Annoying customers and forcing them out of your business into the willing hands of your competition?

[joshstrange]

It's amazing how you, knowing nothing about my stack/use-case can speak with such authority. Going as far as to assume that we must be in a "'downfall of the Roman Empire' phase" because I see value in magic links and because I don't want to implement password support, again, in a product you know nothing about.

I have a very good reason for picking magic links, also the codebase for my project does not ruse a framework (there exist no good ones in the space I'm in) but instead of being curious you decided to be condescending. Cool.

[kevincox]

> You specifically complained about having to enter your email on the magic link flow:

For logins yes:

> My email address never auto-fills so I need to click the field and select the completion suggestion. This is even worse if I am using a per-site email address.

My email always autofills for regular login forms. Maybe this is a bug in my browser but either way it is an inconvenience that I face.

> implementing and maintaining a number of things like your salt, password complexity requirements, password reset flow

If you are using any halfway popular language there is a library that does all of this for you. In fact it is probably easier to use a pre-packaged library than for magic links, but I'm sure those libraries could appear if magic links become more popular.