A heck of a wild bug chase
georgemauer.net
A heck of a wild bug chase
1–10 of 59 posts
Re: A heck of a wild bug chase
#2It 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.
Re: A heck of a wild bug chase
#3It 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.
Re: A heck of a wild bug chase
#4It 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 beyond that even if you're only trying to learn just the foundations how do you know what those foundations are if you're not already inundated in that stack?
This is mostly just my personal ramblings, but I'd be curious other peoples viewpoints on this.
Re: A heck of a wild bug chase
#5It 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…
While it may not be quite the same answer you're looking for, I'd suggest the OWASP, and at least their top 10 for sure. Learning about SSRF may not have stopped this behavior (it's coming from the authenticated browser), but if you're doing CSRF checks you won't get logged out by random links on other peoples sites, and that whatever logged you out was a legitimate action.
Re: A heck of a wild bug chase
#6I always do logout so there is no url to accidentally GET call anyways.
Re: A heck of a wild bug chase
#7It 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…
I remember many years ago when I used to read print magazines about programming and web development.
One of those magazines told a story about a web site that had lost a lot of data. What had happened? Well, somehow they had this page that
1. Required no authentication at all, and
2. Was using links like
Delete file
That’s when I learned about the importance of using forms with POST requests for certain actions instead of using links that send GET requests.
And then some years later someone told me about this thing called HATEOAS and about RESTful APIs and that actually there are different HTTP verbs you can use other than just GET and POST. Like for example
DELETE /path/to/file
Ideally whatever web development tutorials or courses or books they are using would at some point tell them about the different HTTP verbs that exists, and of how and when to use each of them, and crucially to tell them about bad consequences of using GET for anything that has side-effects like logging out a session or deleting a file.
Re: A heck of a wild bug chase
#8It 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.
This is a very good example where the HTML extensions that alex proposed here:
https://www.youtube.com/watch?v=inRB6ull5WQ
(TLDW: allow buttons to make HTTP requests; allow buttons & forms to issue PUT, PATCH & DELETE; allow buttons, forms & links to target elements in the DOM by id instead of only iframes)
would improve the web platform. You could have a stand-alone logout button that issues a DELETE to /session or whatever. Nice and clean.
Re: A heck of a wild bug chase
#9It 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 that the `Link` component in NextJs
- does preloading by default (which is a bad idea exactly for the above reason of reality being different from theory)
- doesn't do preloading by default when running on the dev server (so you don't see the error until its deployed)
- because it does preloading directly in javascript, it can't possibly follow the HTTP semantic of not actually applying cookies until later when the cached route is used
Everything else was the wild goose chase bits.
Also I asked claude to criticize the article as a web forum might before publishing, and this is definitely the tone it gave :D
Oh, also, I'm pretty sure I got the part wrong where i was talking about the preload attribute in HTML, but so far no one's noticed. I should correct that.
Re: A heck of a wild bug chase
#10I 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.