Logout: GET or POST?

Question

This question is not about when to use GET or POST in general; it is about which is the recommended one for handling logging out of a web application. I have found plenty of information on the differences between GET and POST in the general sense, but I did not find a definite answer for this particular scenario.

As a pragmatist, I'm inclined to use GET, because implementing it is way simpler than POST; just drop a simple link and you're done. This seems to be case with the vast majority of websites I can think of, at least from the top of my head. Even Stack Overflow handles logging out with GET.

The thing making me hesitate is the (albeit old) argument that some web accelerators/proxies pre-cache pages by going and retrieving every link they find in the page, so the user gets a faster response when she clicks on them. I'm not sure if this still applies, but if this was the case, then in theory a user with one of these accelerators would get kicked out of the application as soon as she logs in, because her accelerator would find and retrieve the logout link even if she never clicked on it.

Everything I have read so far suggest that POST should be used for "destructive actions", whereas actions that do not alter the internal state of the application -like querying and such- should be handled with GET. Based on this, the real question here is:

Is logging out of an application considered a destructive action/does it alter the internal state of the application?

Answer 1

Well if you let your web application abandon the session through a log out script, you usually don't need either. Normally there's a session variable that's unique for the session you want abandoned.

Answer 2

To be correct, GET/POST (or other verbs) are actions on some resource (addressed by URL) - so its generally about resource's state and not about application state as such. So in true spirits, you should have a URL such as [host name]\[user name]\session, then 'DELETE' would be the correct verb for log out action.

Using [host name]\bla bla\logout as URL in not really an REST full way (IMO), so why debate about correct use of GET/POST on it?

Of course, I also use GET to an logout url in my applications :-)

Answer 3

The reason to avoid GET, as you observed, is "destructive actions," or actions that alter state. These are the things that you really don't want Google's Spider to do. For instance, deleting products from your catalog or placing fake orders is one of these things. Logout alters state in your application; it is thus also a destructive action.

In the case of logging out, though, you can't possibly go wrong: how is a web spider going to accidentally log in, in the first place? If GET is easier to implement, then you should do it.

(Pedantically speaking, I believe logging out should DELETE a "session" object.)

Answer 4

The scenario of pre-caching is an interesting one. But I'm guessing that if lots of sites inc SO do not worry about this then maybe you shouldn't either.

Or perhaps the link could be implemented in javascript?

Edit: As I understand it, technically a GET should be for read-only requests, that do not change application state. A POST should be for write/edit requests that change state. However other application issues might prefer GET over POST for some state-changing requests, and I do not think there is any problem with this.

Answer 5

Logging out does nothing to the application itself. It changes the user's state in relation to the application. In this case, it appears your question is more based on how should the command be initiated from the user to begin this action. Since this is not a "destructive action", sure the session is abandoned or destroyed but neither your application or your data is altered, it is not infeasible to allow both methods to initiate a log out procedure. The post should be used by any user initiated actions (e.g. - user clicks "Log out"), while get could be reserved for application initiated log outs (e.g. - an exception detecting potential user intrusion forcibly redirects to the login page with a logout GET).

Answer 6

in my source code, it only set cookies...

Answer 7

If you use a form submission (using GET) to log out, instead of a link, your problem is solved as no accelerator would auto submit a form.

Answer 8

In REST there should be no session, therefore there is nothing to destroy. A REST client authenticates on every request. Logged in, or out, it's just an illusion.

What you are really asking is should the browser continue sending the authentication information on every request.

Arguably, if your application does create the illusion of being logged in, then you should be able to to "log out" using javascript. No round trip required.

---

Fielding Dissertation - Section 5.1.3

each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client

Answer 9

One way GET could be abused here is that a person (competitor perhaps:) placed an image tag with src="<your logout link>" ANYWHERE on the internet, and if a user of your site stumbles upon that page, he will be unknowingly logged out.

Answer 10

Simple answer: I almost always use GET. I haven't had a problem and many other sites also do this.

Answer 11

I don't see how loging out (de-elevating user permissions) is a desctructive action. Thats because the "logout" action should be only available to users that are already logged in else it would be obsolete.

A random generated string contained in your browser cookies is all representing your user session. There are tons of ways to destroy it so effectively logging out is merely a service to your visitor.