6 ms·

Modifying session state should be a POST, not a GET.

by dylz 13y ago

callesgg 13y ago
It is more than often not. Google mail is one example. But i do concur.
yogo 13y ago
In theory yes, but I'd wager that most of the time logouts are just hyperlink (/account/signout, /logout, etc.). Unless you had a good reason to, you kinda have to go out of your way to make it a POST.
- ecesena 13y ago
  From a security point of view this is not good. An attacker can embed the logout link wherever (e.g. send a tweet) and logout your users. As said in the parent post, GETs should be idempotent and, in particular, not change any state.
  - yogo 13y ago
    I totally agree. What I'm outlining is that it is very convenient to implement it as a simple anchor tag, hence that is what you usually see in the wild.
    - bpicolo 13y ago
      Not the libraries' fault if you do something stupid.
  - hnha 13y ago
    That's what tokens are for but I agree that POST is the way to go.
- adambard 13y ago
  I feel using a library like this would constitute a good reason.
- windsurfer 13y ago
  So you're saying that poorly-designed applications wouldn't work properly sometimes.
  - mherkender 13y ago
    Poorly designed applications like this one? https://accounts.google.com/Logout https://accounts.google.com/Logout
    - jodrellblank 13y ago
      Yes. What's your point? Google must be incapable of poor design? Everything a big company does is good?
      - mherkender 13y ago
        I wanted to know what HN consensus was on this sort of thing, because it seems to me this is not something that inexperienced programmers do (like SQL injection). Also, full disclosure: I work for Google.
    - windsurfer 13y ago
      Yes. Imagine if everyone put the following code on their sites: <iframe src="https://accounts.google.com/Logout" width="0" height="0" ></iframe>
      - snikch 13y ago
        I believe that would be the point of <meta http-equiv="X-Frame-Options" content="deny">
        codygman 13y ago
        That's like trying to duct tape your arm back on after losing a fight with a chainsaw.
        mike-cardwell 13y ago
nimish 13y ago
It ought to be a PUT since it's idempotent but still modifies state. It definitely should not be a GET, since good practice says that GET is idempotent (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) Nobody ever follows this since we all want stuff like www.example.com/articles/latest to respond to GET and also have different content depending on time. The distinction is at the core of the REST abstraction and it's an art.
- StavrosK 13y ago
  It clearly says that GET's side effects should be the same every time it's run. It doesn't say data retrieved by GET can never, ever change.
  - codygman 13y ago
    It shouldn't have side effects and be idempotent though. At least if you are adhering to the RFC.
- michaelmior 13y ago
  Curious where you get the rationale that idempotent state updates should be PUT requests and not POST.
  - steveklabnik 13y ago
    Because PUT is idempotent and POST is not. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...
- derefr 13y ago
  Oh, are we talking HATEOAS session support? # if you don't have a session token yet POST /session-tokens # Accept: application/json => 200 {"token": "someuuid"} # no cookies set! # stuff the session token in localStorage instead # now use it PUT /sessions/someuuid # with your login details => 201 GET /sessions/someuuid/inbox # Accept: application/json => 200 {...} GET /sessions/someuuid/inbox # again => 304 # wow much cached # meanwhile GET /sessions/otheruuid/inbox => 200 {...} # other user: other memcached prefix! # pages that won't change per-user... GET /home => 304 # can be cached globally # (use JS client-side, not edge-side, includes) # and finally... DELETE /sessions/someuuid => 301 /home # log out! Basically, a session is just another resource that you create and then manipulate using its sub-resources. This makes all sorts of things easier: creating session tokens and attaching sessions to them (by logging in, or as a guest) are separate steps, so you can throttle logins at the just by throttling access to the token generator. No cookies and no ESI means caching (reverse-)proxies can actually cache. (Note that I'm presuming TLS and hygienic CORS here, so "session stealing" isn't a valid complaint. Or rather, without those things, it's just as valid a complaint for a cookie-based approach.) Oh, but as a postscript, one little HATEOAS bonus tweak: POST /session-tokens => 200 {"token": "/sessions/someuuid"} # no constructing URIs!

Modifying session state should be a POST, not a GET.

by dylz 13y ago

Modifying session state should be a POST, not a GET.

callesgg 13y ago

It is more than often not. Google mail is one example. But i do concur.

yogo 13y ago

In theory yes, but I'd wager that most of the time logouts are just hyperlink (/account/signout, /logout, etc.). Unless you had a good reason to, you kinda have to go out of your way to make it a POST.

ecesena 13y ago
From a security point of view this is not good. An attacker can embed the logout link wherever (e.g. send a tweet) and logout your users. As said in the parent post, GETs should be idempotent and, in particular, not change any state.
- yogo 13y ago
  I totally agree. What I'm outlining is that it is very convenient to implement it as a simple anchor tag, hence that is what you usually see in the wild.
  - bpicolo 13y ago
    Not the libraries' fault if you do something stupid.
- hnha 13y ago
  That's what tokens are for but I agree that POST is the way to go.
adambard 13y ago
I feel using a library like this would constitute a good reason.
windsurfer 13y ago
So you're saying that poorly-designed applications wouldn't work properly sometimes.
- mherkender 13y ago
  Poorly designed applications like this one? https://accounts.google.com/Logout https://accounts.google.com/Logout
  - jodrellblank 13y ago
    Yes. What's your point? Google must be incapable of poor design? Everything a big company does is good?
    - mherkender 13y ago
      I wanted to know what HN consensus was on this sort of thing, because it seems to me this is not something that inexperienced programmers do (like SQL injection). Also, full disclosure: I work for Google.
  - windsurfer 13y ago
    Yes. Imagine if everyone put the following code on their sites: <iframe src="https://accounts.google.com/Logout" width="0" height="0" ></iframe>
    - snikch 13y ago
      I believe that would be the point of <meta http-equiv="X-Frame-Options" content="deny">
      - codygman 13y ago
        That's like trying to duct tape your arm back on after losing a fight with a chainsaw.
      - mike-cardwell 13y ago

nimish 13y ago

It ought to be a PUT since it's idempotent but still modifies state. It definitely should not be a GET, since good practice says that GET is idempotent (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) Nobody ever follows this since we all want stuff like www.example.com/articles/latest to respond to GET and also have different content depending on time. The distinction is at the core of the REST abstraction and it's an art.

StavrosK 13y ago
It clearly says that GET's side effects should be the same every time it's run. It doesn't say data retrieved by GET can never, ever change.
- codygman 13y ago
  It shouldn't have side effects and be idempotent though. At least if you are adhering to the RFC.
michaelmior 13y ago
Curious where you get the rationale that idempotent state updates should be PUT requests and not POST.
- steveklabnik 13y ago
  Because PUT is idempotent and POST is not. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...
derefr 13y ago
Oh, are we talking HATEOAS session support? # if you don't have a session token yet POST /session-tokens # Accept: application/json => 200 {"token": "someuuid"} # no cookies set! # stuff the session token in localStorage instead # now use it PUT /sessions/someuuid # with your login details => 201 GET /sessions/someuuid/inbox # Accept: application/json => 200 {...} GET /sessions/someuuid/inbox # again => 304 # wow much cached # meanwhile GET /sessions/otheruuid/inbox => 200 {...} # other user: other memcached prefix! # pages that won't change per-user... GET /home => 304 # can be cached globally # (use JS client-side, not edge-side, includes) # and finally... DELETE /sessions/someuuid => 301 /home # log out! Basically, a session is just another resource that you create and then manipulate using its sub-resources. This makes all sorts of things easier: creating session tokens and attaching sessions to them (by logging in, or as a guest) are separate steps, so you can throttle logins at the just by throttling access to the token generator. No cookies and no ESI means caching (reverse-)proxies can actually cache. (Note that I'm presuming TLS and hygienic CORS here, so "session stealing" isn't a valid complaint. Or rather, without those things, it's just as valid a complaint for a cookie-based approach.) Oh, but as a postscript, one little HATEOAS bonus tweak: POST /session-tokens => 200 {"token": "/sessions/someuuid"} # no constructing URIs!