6 ms·
POSTs are not Links. And Logout service is indempotent even if you can consider it changes the state of the system
by slim 8y ago
POSTs are not Links. And Logout service is indempotent even if you can consider it changes the state of the system
- glacials 8y agoIdempotency is not the issue, the issue is that a user might hover over the logout link, not click it, then move on to the rest of the site and find they are logged out for no reason.
- enedil 8y agoThat's exactly the problem with idempotency.
- winstonewert 8y agoactually, no. Idempotency means that you can safely do the same operation multiple times with the same effect as doing it once. That's a different issue than the no-side-effects rule which GET is supposed to follow.
- leesalminen 8y agoRight, which is why the included library includes an HTML attribute to disable prefetch on a given link.
- pbreit 8y agoOP’s point was that logout should not be implemented with a link/GET but instead with a button/POST for exactly this reason.
- leesalminen 8y agoA logout action is idempotent, though. You can't get logged out twice. In my opinion, that's the use case for a GET request. I just checked NewRelic, Twilio, Stripe and GitHub. The first 3 logged out with a GET request and GitHub used a POST.
- hateful 8y agoI think this is the argument for PUT instead of POST, not GET instead of POST.
- abathur 8y agoAlso: sometimes a site is misbehaving (for myself, or maybe for a user we're helping) and it's helpful to directly navigate to /logout just to know everyone is rowing in the same direction. Using a POST, especially if you're building through a framework that automatically applies CSRF to your forms, forecloses this possibility (unless you maintain a separate secret GET-supporting logout endpoint, I guess).
- Guest10928391 8y agoWhen I originally started my community site I used GET for logout. However, users started trolling each other by posting links to log people out. It wasn't easy to control, because a user could post a link to a completely different site, which would then redirect to the logout link. So, I switched to POST with CSRF and never had another issue.
- NewEntryHN 8y agoIdempotence is for PUT requests. GET requests must not have side effects.
- BorRagnarok 8y agoI've heard this "get requests shouldn't have side effects" argument before, but I don't think it works. At least, not for me, or I'm doing something wrong. For example: Let's implement authentication, where a user logs in to your api and receives a session id to send along with every api call for authentication. The session should automatically be invalidated after x hours of inactivity. How would you track that inactivity time, if you're not allowed to change state on get requests?
- zepolen 8y agoIdempotency has nothing to do with it. Deleting a resource is idempotent as well. You wouldn't do that via GET /delete A GET request should never, ever change state. No buts. Just because a bunch of well known sites use GET /logout to logout does not make it correct. Doing anything else as demonstrated in this and other cases breaks web protocols, the right thing to do is: GET /logout returns a page with a form button to logout POST /logout logs you out
- Gaelan 8y agoOk, so make it a form/button styled to look like a link.
- deleted 8y ago[deleted]
- nardi 8y agoLots of people in this thread confusing “idempotent” with “safe” as specified in the HTTP RFC: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
- kbirkeland 8y agoFWIW RFC 2616 was obsoleted by the newer HTTP/1.1 RFCs: https://tools.ietf.org/html/rfc7231#section-4.2 https://tools.ietf.org/html/rfc7231#section-4.2
- amenod 8y agoWhich still doesn't change GP's point though: > In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". (there's an exception listed too, but doesn't apply to logout) EDIT: I know of someone who made a backup of their wiki by simply doing a crawl - only to find out later that "delete this page" was implemented as links, and that the confirmation dialog only triggered if you had JS enabled. It was fun restoring the system.
- kbirkeland 8y agoI don't know why you think I'm contradicting them. I was just pointing out that there are newer RFCs. They also happen to have a stronger and more complete definition of safe methods.