Comment by kilburn | Hacker News Reader

Comment by kilburn | Hacker News Reader

> Know why it’s important that your GET requests should always be idempotent. For example, your sign-out should only work as a POST request so that someone cannot make your users sign out by just including an <img> tag in their forum signature.

You got that mixed up. Idempotent requests mean that the result is exactly the same even if issued multiple times. In the case of a logout, idempotency is pretty much granted even when using GET requests. The idea here is that GET request should not change the state of the application, because the browsers are happy about opening the same URL multiple times without user confirmation. For instance, a "post/delte/last" URL that deletes your last post would be a terrible idea, because of the following scenario:

  1. The user goes to the "post list", */posts*
  2. The user hits "delete last post", and the web sends him to */posts/delete/last*
  3. The user goes somewhere else, */somewhere*
  4. The user decides he would like to go back, and clicks "back". His browser opens */posts/delete/last* without any warning. _Ops!_ he has just deleted another post without even noticing!

The <img> URL issue is a separate concern: that of Cross-Site Request Forgery (CSRF). The easiest way to protect from this security issue is to require a single-use token for each request that changes the application state. You can read more about it at the Open Web Application Security Project website: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%...

The main problem here is that "idempotent" means something different in math/CS than it colloquially does in HTTP.

In math/CS, "idempotent" means "has the same effect when done 1 time as when done n>1 times."

In HTTP, GET requests are often described as "idempotent" by someone who actually means "nullipotent" (i.e. "has the same effect when done 0 times as when done n>0 times"). This is because the spec describes GET, PUT, and DELETE requests as idempotent - which they are, it's just that GET requests are nullipotent as well.

Wikipedia mentions this briefly:

http://en.wikipedia.org/wiki/Idempotent#Computer_science_mea...

His solution isn't as secure as CSRF protection, but it would cover the basic case easily. All you have to do is pretend logging out isn't idempotent.

logout is not idempotent. If you send a log-out request, the system will log you out. All subsequent attempts will do nothing.

Therefore the results are different for different states and it is not idempotent.

I don't think you quite understand the definition of idempotent. A process is idempotent is if the process can be applied multiple times without changing the result achieved from the first application.

In this case, logging out multiple times does not change anything from the first application.

you're making way too much assumption as to what logout does behind the scenes. "without changing result" != "without changing state"

sending notifications, updating counters, etc. all could be result of logging out.

I think it is easy for us to agree in that, from the client's point of view, logging out of a website is idempotent.

Now, you got a point about idempotence from the server's point of view. However, it would take a _badly_ programmed website for the logout operation to _not_ be idempotent. Sending notifications, updating counter, etc. _without first checking if the user is really logged in or not_ is simply moronic. This simple check is what would turn the logout operation into an idempotent one in the server too.

> Therefore the results are different for different states and it is not idempotent.

No, from all states, the result is that you're logged out.

I don't think this is the right way to think about it. The ending "state" might be the same, but the output of the first logout operation would be "change of state: logged in -> logged out". In the second case, however, it would be "no change in state". It does different things under different circumstances.

From the Wikipedia article on Idempotence [1]:

  Similarly, changing a customer's address is typically
  idempotent, because the final address will be the same 
  no matter how many times it is submitted.

So, even if in one case there's an internal state change (going from an old address to a new one) whereas in the other there is not (going from the new address to the new one again), it is commonly considered idempotent because the end result is the same.

[1] http://en.wikipedia.org/wiki/Idempotence#Computer_science_me...

Okay, I understand that the formal definition of "idempotent" is different than what the author means. What is the correct term to use in this case?

Edit: Next paragraph says:

  This is a very useful property in many situations, as it means that an operation can
  be repeated or retried as often as necessary without causing unintended effects.
  With non-idempotent operations, the algorithm may have to keep track of whether the
  operation was already performed or not.

"A change in state" would be an unintended effect I think.

I think the best "term" you can use here is "side effect free". I almost wanted to say "pure" would work, but there is no real requirement that GET always return the same thing: it just needs to not change the state of the server in a way that a later GET could detect (although, honestly, you really only practically care about "find bothersome", and if there is a term for "bothersome side effect free" it would probably be from medicine and not computer science).

"Idempotence is the property of certain operations in mathematics and computer science, that they can be applied multiple times without changing the result beyond the initial application."[1]

[1] https://en.wikipedia.org/wiki/Idempotence

What is the definition of "result". My point is that result in this case is a "change of state" vs "no change in state".

the result of multiple log out attempts will be "attemptor will be logged out."

"Methods can also have the property of "idempotence" in that ... the side-effects of N > 0 identical requests is the same as for a single request." [1]

The HTTP spec clearly talks in terms of the effect of sequences of repeated operations, not in terms of the results of individual operations. The side effects of a single logout are the same as for 6 - you are logged out and whatever logout triggers exist are executed once.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...

Reply on news.ycombinator.com