5 ms·
Realy Cool, Only real problem with this is if the clicking has side effects like: http://example.com/?action=logout http://example.com/?action=logout as brought
by callesgg 13y ago
Realy Cool,
Only real problem with this is if the clicking has side effects like: http://example.com/?action=logout http://example.com/?action=logout
as brought up on page.
And probably a ton of other application bugs as style and script stuff wont load. like they normally would
- dieulot 13y agoYou can blacklist these links (or whitelist all the other links).
- mrfusion 13y agoWould it be worth blacklisting logout by default? Maybe blacklist any links with the words logout, delete, etc anywhere inside the a tag or in the attributes?
- dieulot 13y agoNo, my philosophy is to not do anything that could get into one’s way. And that’s a false sense of security. If one is worried about preloading links that triggers an action, there is a whitelist mode to enable links as you review them.
- fudged71 13y agoCould this be used on every website if it were a browser extension? If it were, I would expect Logout links to be disabled by default.
- dylz 13y agoModifying session state should be a POST, not a GET.
- callesgg 13y agoIt is more than often not. Google mail is one example. But i do concur.
- yogo 13y agoIn 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 agoFrom 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 agoI 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 agoNot the libraries' fault if you do something stupid.
- hnha 13y agoThat's what tokens are for but I agree that POST is the way to go.
- adambard 13y agoI feel using a library like this would constitute a good reason.
- windsurfer 13y agoSo you're saying that poorly-designed applications wouldn't work properly sometimes.
- mherkender 13y agoPoorly designed applications like this one? https://accounts.google.com/Logout https://accounts.google.com/Logout
- nimish 13y agoIt 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 agoIt 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 agoIt shouldn't have side effects and be idempotent though. At least if you are adhering to the RFC.
- michaelmior 13y agoCurious where you get the rationale that idempotent state updates should be PUT requests and not POST.
- steveklabnik 13y agoBecause 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 agoOh, 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!