Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Come to think of it, magic links by definition violate the principle that GET requests should not change state. Defender & preview tools are actually following the established norms here - norms that were established decades ago precisely because we hit the more broad problem with C, U & D parts of CRUD, and collectively agreed that doing destructive operations on GET requests is stupid.

View on HN

You can GET a <form> which POSTs when you click the "log in" button.

Yes, but the GET itself isn't changing any state. The state changes only after clicking on the button. This is OP's point.

TeMPOraL said, "magic links by definition violate the principle that GET requests should not change state". That is a reasonable thing to think, but it is not true, because you can GET a <form> which POSTs when you click the "log in" button, unless you think a link to such a <form> page should be excluded from the definition of "magic link".

> unless you think a link to such a <form> page should be excluded from the definition of "magic link".

Yes. Linking to a form requiring user to press a button to submit an actual POST request is one proper way of doing it, and won't confuse prefetchers, previewers and security scanners - but it lacks the specific "magic" in question, which is that clicking on a link alone is enough to log you in.

Can't really have both - the "magic" is really just violating the "GET doesn't mutate" rule, rebranding the mistake we already corrected 20+ years ago.

(EDIT: Also the whole framing of "magic links" vs. passkeys reads to me like telling people that committing sins is the wrong way of getting to hell, because you can just ask the devil directly instead.)

Aha, then we agree on the facts, just disagree about nomenclature.

Your theological analogy is hilarious!

In your example, it seems to me that the POST request is the action that changes the state.

Agreed.

This is the way.

Reply on news.ycombinator.com