Live data from Hacker News

A heck of a wild bug chase

georgemauer.net

11–20 of 59 posts

Re: A heck of a wild bug chase

#11

I always do logout so there is no url to accidentally GET call anyways.

This is the worst of both worlds, it doesn't conform to the spec and it has incorrect semantics. See HTMHell [0] for a brief discussion on the topic, albeit with a slightly different example. [0] https://www.htmhell.dev/8-anchor-tag-used-as-button/

ok fine logout but at least / is safe to GET

Re: A heck of a wild bug chase

#12
post #2

It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.

Author of the post here, There was no form submission, I'm not sure where you got that. There was also no POST. Though yes, I agree that in the core HTTP semantic, you wouldn't want to change state on a GET and that should include not calling `Set-Cookie`. And yet the reality is that that nearly every application - and many popular libraries like auth0 - do in fact set and clear cookies on `GET`. The issue here was t…

> There was no form submission, I'm not sure where you got that. There was also no POST.

OP was saying the logout function should have been behind a form submission / POST.

Re: A heck of a wild bug chase

#14
post #4
post #2

It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.

Genuine question: How do you believe one should learn these semantics? This is more something I've been pondering myself recently, because I agree with you that the foundational knowledge for our work in any tech stack is usually the most important for understanding higher abstractions. But with so much to know it feels impossible to 'know it all' so to speak especially if you wear more than one specialized hat. Then…

It requires slowing down. Unheard of.

Re: A heck of a wild bug chase

#15
Authentication is a major hurdle. Back in the days of desktop software, there was no authentication. Mobile apps can often avoid authentication too. Despite decades of web coding, and lots of "this authentication system will make life easy" claims, it is still hard and easy to mess up.

Re: A heck of a wild bug chase

#18

Earlier quoted context omitted.

Author of the post here, There was no form submission, I'm not sure where you got that. There was also no POST. Though yes, I agree that in the core HTTP semantic, you wouldn't want to change state on a GET and that should include not calling `Set-Cookie`. And yet the reality is that that nearly every application - and many popular libraries like auth0 - do in fact set and clear cookies on `GET`. The issue here was t…

> There was no form submission, I'm not sure where you got that. There was also no POST. OP was saying the logout function should have been behind a form submission / POST.

Ah, yes, I mean, agree that would have been technically correct, but like I said, its just not how a lot of the web works. auth0-nextjs seems to react to `GET` by default (though it might also work with `POST` and you certainly can override things)

Re: A heck of a wild bug chase

#19
post #13

Earlier quoted context omitted.

Why make it a link if you aren't linking to anything?

so you don't have to set "cursor: pointer" in css

And it gives some baseline accessibility functionality. Sucks that there isn't any gerneral "I am clickable" element that neither has bad default click behavior, nor has its own likely-unfitting styling.

Re: A heck of a wild bug chase

#20
post #3
post #2

It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.

To be fair, tags can't send out non-GET requests. Which yes, can be interpreted as "logout controls should be buttons in forms, not links", but I would really like native htmx-like attributes for intractable html elements.

What’s stopping you from using htmx with a form? Hx-post works as a form element attribute just fine.
Post reply on HN