Logout: GET or POST?

500
votes

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?

9
architecturerestpostget
Well, assuming you are visiting the site for the first time, and the logout link is not present, you would be logged out when you login. It would be fine after you logged in a second time, since the logout url is already cached. But one can assume any decent accelerator would be able to filter out most logout urls. – HyperCas
HyperCas, accelerators filtering out logout URLs was a theory I was considering and one of the reasons I decided to post the question. I feel a little reluctant to just trust the accelerator logic, and one day have a user with a crappy accelerator complain that she can't login. Do you know if they follow a standard, or if such standard exists? – Daniel Liuzzi
Any Accelerator that automatically submitted a form (for example) would be malware IMO... it is totally illogical to think that an accelerator would submit a form automatically. Imagine you visit Google. How could it submit the search form? Nobody can account for Malware as it is too unpredictable and does not follow the rules. – Alex
@AlexW - I think you misunderstood my question. The accelerator scenario I proposed is to show a possible issue when using GET, not POST, so there would be no form to post, only plain links which accelerators would have no problems following. – Daniel Liuzzi
I realise I'm years too late for this, but Alex, that's not what Daniel is asking about. He's saying that if a user clicks a logout link and an accelerator returns the cached logout page without it hitting the application, then the user would stay logged in. Nothing to do with malware, although FYI checking a User-Agent string wouldn't fix anything anyway. – Rob Grant

9 Answers

547
votes

Use POST.

In 2010, using GET was probably an acceptable answer. But today (in 2013), browsers will pre-fetch pages they "think" you will visit next.

Here is one of the StackOverflow developers talking about this issue on twitter:

I'd like to thank my bank for making log off a GET request, and the Chrome team for handy URL prefetching.- Nick Craver (@Nick_Craver) January 29, 2013

fun fact: StackOverflow used to handle log-out via GET, but not anymore.

50
votes

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

42
votes

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.

26
votes

Hello on my point of view, when you login you check username / password and if those are matching you create the login token.

CREAT token => method POST

When you are logging out you distroy the token so to me the most logical method should be a DELETE

DELETE token => method DELETE

23
votes

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 :-)

17
votes

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).

1
votes

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.

0
votes

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.

-2
votes

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.