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?

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, Aug 19 '10 at 12:10
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, Aug 19 '10 at 12:33
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, Aug 19 '10 at 12:47
@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, Aug 19 '10 at 12:53
Fair enough. I would suggest then checking the User-Agent of the GET request and to verify it was the browser and not another piece of software. If not User-Agent then an equivalent property in the EventHandler object. — Alex, Aug 19 '10 at 12:56
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, Aug 20 '13 at 06:03

David Murdoch · Accepted Answer · 2013-01-30T22:27:44.430

649

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.

edited Jan 30 '13 at 22:27

answered Jan 29 '13 at 16:14

David Murdoch

87,823
39
148
191

3

Thanks for this update, Dave. I didn't even notice SO switched their log out to POST, and I honestly had no clue Chrome comes with pre-fetching built in. Finally, the twit you quoted was could have never offered a better example to the problem I described in my my question and confirms my suspicions. I am up voting your answer and making it the accepted answer. – Daniel Liuzzi Feb 05 '13 at 05:16
4

In my browser, Stackoverflow logout looks like
log out

boatcoder

Feb 22 '13 at 14:40

11

@Mark0978, click the link. – David Murdoch Feb 22 '13 at 14:47

3

Interesting. That's probably one of my least favorite features, a logout that then asks me if I'm sure. Guess it keeps the prefetch from logging you out, but Amazon, Ebay, and Gmail all use GET for logout without that trick page in between what the user is told is logout and the actual logout event. I would imagine that in between page would lead to a lot of people mistakenly believing they were logged out. The problems with that on SO are minimal, no money involved, and 99% of everything is public anyway. – boatcoder Feb 22 '13 at 15:00

@DavidMurdoch Do you know how SO creates the hidden 'fkey' value that is posted along with the logout action (for security purposes)? – Ethan May 31 '13 at 21:34

The blame here lies on the browser part, not on the remote side. Web page can't know about what nonstandard mechanisms were built into a browser and it's silly to expect it will adopt. – Red Sep 19 '13 at 11:45

2

@Ethan I would suspect that's for CSRF prevention, and as a rule of the thumb, should accompany any POST operation. Frameworks usually provide out of the box solutions to this. e.g., Django's `csrf_token` template tag. – yati sagade Mar 30 '14 at 18:25

10

@Red According to the HTTP/1.1 standard, this is the server's fault, not the browser's. GET is expected to have no side-effects on the server side. The standard even says "the user did not request the side-effects, so therefore cannot be held accountable for them". – eyuelt Apr 14 '14 at 22:27

2

@eyuelt I'd argue that, when session is marked by setting a cookie in user's browser, removing it does not constitute server-side effect. In fact, cookies get set and removed on GET requests all the time. – Red Apr 21 '14 at 12:23

@Red Good point. So I guess it is the browsers' fault. But now that many browsers are doing pre-fetching, it's probably best to stop using GET for things like that. Though it may not be in line with the standard, you're very unlikely to get browsers to stop pre-fetching, especially mobile browsers, as it impacts performance pretty significantly. – eyuelt Apr 21 '14 at 17:57

1

I don't think it has ever been a good idea to use GET for operations different than read-only ones. On MDN `GET` is marked as `Safe`, which means `...it doesn't alter the state of the server. In other words, a method is safe if it leads to a read-only operation.` – undefined Mar 06 '21 at 10:18

@boatcoder I can't even find the logout in SO anymore. So I guess the answer to this question is "remove the option to logout". No more need to worry if it is GET or POST. – 2Noob2Good Jan 30 '23 at 23:00

1

Out of curiosity, browsers are "prefetching" content on your behalf? So basically, Google can crawl apps logged as us. Well, I know they can do whatever they please but still... It feels pretty awkward. It's like the browser implement what they want and if it destroys the behavior of millions of websites it's ok. It's hard to believe. This still happens? I never had any problem with GET logouts. I will start to use POST but still I am quite shocked about all this. – 2Noob2Good Jan 30 '23 at 23:08

So, what is the solution when you want to force a logout from code? I have a Blazor server app and so I can't call the UserManager from my code. I need to do a GET on a MVC page that will do it. But then it's a GET. Details at https://stackoverflow.com/questions/76371849/how-can-i-logout-programmatically-identity-in-a-blazor-server-app – David Thielen May 31 '23 at 09:11

Darrel Miller · Answer 2 · 2010-08-19T12:56:16.573

58

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

edited Aug 19 '10 at 12:56

answered Aug 19 '10 at 12:30

Darrel Miller

139,164
32
194
243

1

I actually was not aware of this. Then I guess my app won't be very RESTful at all, as I'm using ASP.NET MVC with FormsAuthentication and it relies on sessions... – Daniel Liuzzi Aug 19 '10 at 12:40
@Daniel I added the relevant section from the definition of REST. – Darrel Miller Aug 19 '10 at 12:56
36

but in practice the login info is kept in a cookie marked with the `httponly` attribute to prevent some xss risks, which means it can only be reset from the server (short of manually clearing the cookie) – Remus Rusanu Aug 19 '10 at 14:41
6

'Manual' as in the user goes to the Browser settings and chooses the 'Clear cookies' option. Hardly an acceptable way to 'log off' a web site. – Remus Rusanu Aug 19 '10 at 19:39
1

@Remus Ahhh, how the illustrious web browser makes writing web apps so painful. – Darrel Miller Aug 19 '10 at 20:27
In addition to @RemusRusanu's comment, there is a security issue: If my cookie is somehow stolen, and I subsequently logout, I expect (and should expect) the attacker's session to be dead as well. This can be accomplished without classic "sessions" too: If each user has a mutable secure id regenerated on every login (in addition to an immutable sequential id), this can be stored in the cookie as the userid and destroyed on logout. Each request still has all the info needed to authenticate, but logout will be secure and behave as you'd expect. – Jonah Jul 20 '16 at 06:39
Statement "...therefore there is nothing to destroy..." is not fully true. Good practise should be destroy/invalidate auth token on server side too, not only in client. – Petr Pánek Apr 20 '19 at 03:21
@PetrPánek Unless you are using reference tokens there is no token to delete on the server. With OpenID Connect compliant OAuth2 the bearer token is a signed JWT that is completely self-descriptive. – Darrel Miller Apr 20 '19 at 20:26
4

@DarrelMiller yes however not revoking a JWT on the server side is a security vulnerability. Even if the tokens are not stored on the server, they should be blacklisted when a user logs out/changes passwords/changes roles/quits/etc to prevent abuse (at least until they expire). – java-addict301 May 15 '19 at 19:27
This is the most correct answer. Unless you are working with a resource server-side, there is nothing to "logout" on the server. – Jakub Keller Dec 13 '19 at 02:23
1

If we think of a session as we think of an API key, I believe we should think of logging out as we think of invalidating an API key. In my REST application, a session (which is an alphanumeric ID) is being sent instead of an API key. A list of these sessions, their permissions, expiry, etc. is stored on the server, as you most likely would with an API key. It is true that you would hardly need to invalidate an API key, but what about access tokens? As far as I'm informed, access tokens should only be used for a limited time and it makes a lot of sense to want to invalidate them sometimes. – undefined Mar 06 '21 at 10:15

score 47 · Answer 3 · answered Aug 19 '10 at 13:01

47

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.

answered Aug 19 '10 at 13:01

raveren

17,799
12
70
83

7

No, this is not right. A log out link will only work if the correct cookie data is sent, which it will not be from another domain. And even if the session id is stored in the url, that wouldn't work either as these change for every session. – Richard H Aug 19 '10 at 13:36
5

Wow, I never thought of that! So there, another reason not to use GET, and another reason I don't understand why everybody does it. Damn it, now I'm temped to include a http://stackoverflow.com/users/logout "image" too my post and see what happens :-D – Daniel Liuzzi Aug 19 '10 at 13:45
@Richard - Makes sense, but the problem would exist in community-driven sites such as SO, right? The domain would be the same in this case. – Daniel Liuzzi Aug 19 '10 at 13:53
@Daniel: I'm not sure cookie data is sent with an image request - although I never thought about this! But I doubt it. – Richard H Aug 19 '10 at 14:10
30

src= is a simple browser request, it does not come from server side, but from the client. It carries all cookies and comes from the user IP. That is why ad tracking pixels work. Only way to determine such exploit would be to check the referrer. – raveren Aug 19 '10 at 15:32
@Raveren: Checking the referrer could work, but unfortunately it isn't very reliable, as it merely is a header sent by the browser, so it's trivial to alter/fake. Namely, there's a Firefox extension called RefControl (https://addons.mozilla.org/firefox/addon/953) that allows you to do just this. – Daniel Liuzzi Aug 19 '10 at 23:29
18

http://SuperLogout.com does exactly that (load `/logout` URLs in hidden images), and it works. – Dan Dascalescu Jan 28 '16 at 23:59
1

Getting logged out, scary – brettwhiteman Aug 25 '16 at 08:51
26

re:SuperLogout ... I do not know why I clicked that. – Dec 25 '17 at 01:12
4

Yes, that SUPERLOGOUT comment should state by clicking the link users are logged out of Google, Facebook, Amazon and many more popular sites! In case you don't want to be inadvertently logged out. – Stephan Luis Nov 09 '18 at 10:26
1

Actually I want to visit superlogout.com (again) to see how that code works but I do not want to be logged out of Google ... hmmm. Oh here's an article https://www.quora.com/How-do-websites-like-Super-Logout-work – Stephan Luis Nov 09 '18 at 10:36
1

@StephanLuis `view-source:SuperLogout.com`; will not execute any of the GET requests – undefined Mar 06 '21 at 10:21
@raveren in my opinion, the correct way to prevent that would be a CORS policy – undefined Mar 06 '21 at 10:22

score 45 · Answer 4 · edited Sep 01 '22 at 11:54

45

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

CREATE 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

edited Sep 01 '22 at 11:54

openshac

4,966
5
46
77

answered Nov 18 '17 at 22:14

miorey

828
8
19

7

Interesting angle. – Drumbeg Mar 02 '18 at 20:39
1

I use that method in my Spring Boot REST applications. – NaN Oct 31 '18 at 14:12
2

Yes, but the URL for DELETE should identify the resource to delete so it can't be the same one as in the POST. – Ron Inbar Dec 24 '20 at 16:09
3

@RonInbar agreed, if following REST 100%, then the POST to create a session should go to a [host name]/[user name]/session, as VinayC stated below. And DELETE should be like [host name]/[user name]/session/[session_id]. Yet using a DELETE to handle the deletion of session resources, even if getting the resource from a cookie instead of the URL, is better than using another verb to delete a resource (again, if trying to follow REST conventions). – Alvaro Rodriguez Scelza Jul 29 '21 at 18:32
Conceptually this makes sense as long as the URL isn't `/logout`, since you're not deleting a logout (which doesn't make any sense), but deleting a session. So I guess login and logout would both hit the same endpoint, just with POST or DELETE to distinguish them – Matt Browne Mar 15 '22 at 18:56
I just read this and actually would say you're right. It deletes my login, so DELETE /login would be great. But currently PUT and DELETE are not supported by HTML forms as method. Maybe in the future. – Matt Oct 08 '22 at 13:49
i prefer that too – Samir Ghoneim Jan 21 '23 at 16:31

score 24 · Answer 5 · answered Aug 19 '10 at 11:37

24

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

answered Aug 19 '10 at 11:37

VinayC

47,395
5
59
72

2

In that case, I would then argue that having the [user name] part in the URL seems unnecessary, as users always logout from (i.e. DELETE) *their own* session; never other users' :-) – Daniel Liuzzi Aug 19 '10 at 12:09
2

Not really - we are saying that session is an resource and we want to delete it. So for uniformly addressing any session, you need to have user name as a part of URL. Your argument is as good as saying issuing PUT action on [photo gallary]\pictures means you are adding to your photos (available at [photo gallary]\\[user name]\pictures). Different resources has to be addressed explicitly, there can't be any implicitness into it. The site may allow other users to add pictures to your gallery - it would be a part of access control just as you can have a super user who can kill anybody's sessions. – VinayC Aug 19 '10 at 13:06
1

Philosophically speaking, you could call sessions and photos 'resources', but realistically I wouldn't treat them the same. Session are always intrinsically restricted to the current user (hence the name Session) and, at least in ASP.NET, there is no way of accessing another user's sessions. Even the application developer has no direct way of enumerating all active sessions, or means to kill sessions individually. You could restart the application to kill all sessions (InProc), but I wouldn't call that access control. URLs aside, the question still remains: GET or POST? – Daniel Liuzzi Aug 19 '10 at 13:31
1

Resource, hence its address (URL) are important part of REST. So if you choose URL as I said, DELETE becomes the correct word - not GET or POST. Also, even if you are limiting yourself to ASP.NET, you can always have your custom state provider that can give you way to enumerate through sessions and kill other sessions if needed. For out of box in-proc sessions, some fiddling in global.asax should give you the functionality. Its really a question of whether such functionality would be needed or not. For infrequent needs, folks tend to re-start web site to kick people out of site. – VinayC Aug 19 '10 at 13:56
This make the most sense for me. Give the web api a session route and call DELETE on it. Be that ../session or ../session/current. Thankx @VinayC – Simon Hooper Feb 06 '20 at 00:27

Joel Etherton · Answer 6 · 2010-08-19T12:02:18.817

17

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

edited Aug 19 '10 at 12:02

answered Aug 19 '10 at 11:43

Joel Etherton

37,325
10
89
104

This could conceivably depend on the application (some kind of "cascading delete" behavior), but you're right. – Andres Jaan Tack Aug 19 '10 at 14:35
@JoelEtherton Thank you Joel, I was reading down the answers wondering when I would get to the right one. :) – Kirill Fuchs Jan 09 '15 at 21:54
4

It's confusing because logout changes state. POST is the verb for changing state. GET is for getting stateless data. It's confusing because we expect POST requests to have payloads. As noted below, DELETE would be most correct on a session object. – Michael Cole Apr 14 '15 at 10:26
1

@MichaelCole: I would agree with that representation of the difficulty between POST and GET. I wouldn't agree with the usage of the DELETE verb, though. DELETE is for handling a resource, and the session is not a resource in this sense. Consider, if you can DELETE it, then you should also be able to PUT it. – Joel Etherton Apr 14 '15 at 11:23
@JoelEtherton, yes I agree about DELETE and PUT on sessions being a bit weird :-) – Michael Cole Apr 14 '15 at 11:24
Actually, `PUT + DELETE /auth` makes a lot of sense. This implementation also allows you to use `GET /auth` to check which user is currently logged in (404 if none) based on the session cookie. The state of the application _is_ changed by logging in/out, because user sessions can be considered part of this state. It's true that `/auth` represents different user sessions to different users but I think there are other examples of URLs that behave like this. – Ron Inbar Jul 30 '21 at 09:26

score 1 · Answer 7 · answered Aug 19 '10 at 11:39

1

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.

answered Aug 19 '10 at 11:39

Richard H

38,037
37
111
138

Thanks. The *DB* state wouldn't be changed, but the *session* state would. The only problem I see is the one I mentioned in the question, about users getting kicked out. Non-destructive but rather annoying. I usually go by the "if the big guys do it, then it must be OK" mantra too. I just wanted to know what opinion others have on this. – Daniel Liuzzi Aug 19 '10 at 13:09

score 1 · Answer 8 · edited Feb 07 '23 at 07:22

1

According to Mozilla Developer Network web docs anchor (<a>) tags are not prefetched (as of late 2022). There may be other reasons not to use an anchor tag, but accidental logout due to browser prefetching does not seem to be a valid reason according to MDN.

edited Feb 07 '23 at 07:22

Pang

9,564
146
81
122

answered Nov 29 '22 at 05:04

treefiddy

541
6
5

score -1 · Answer 9 · answered Aug 19 '10 at 11:35

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

answered Aug 19 '10 at 11:35

Rob

1,796
14
15

Could you elaborate the "log out script"? I'm not sure if you are referring to setting a cookie expiration (which does not eliminate the need for a way of letting users manually logout.) – Daniel Liuzzi Aug 19 '10 at 11:54
A log out script would end the session of the user (actually: browser) calling it. In ASP.net, the session is a server side object which can be abandoned. PHP has a similar system. Because that browser calls the script that ends the session, it already knows which one to end, eliminating the need for POST or GET variables. – Rob Aug 19 '10 at 12:12
1

Yes, I get you now. I already have the script in place, specifically FormsAuthentication.SignOut(), but my question is about *how* to invoke the script, as in GET or POST. – Daniel Liuzzi Aug 19 '10 at 12:23
Oh you have the url in a form? It doesn't matter if you're not passing any information to it. The worst thing that could happen is someone manually opening the script, logging themselves out. I wouldn't even make it a form field if not neccessary, a link to the script would work as well. If you DO send information to the script, I'd probably go for a POST, so as to not show any information to the user (unless they view the page source), and if they refresh they'll get a warning from their browser (page expired), which might be desirable. – Rob Aug 19 '10 at 13:20

score -2 · Answer 10 · answered Aug 19 '10 at 21:18

-2

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.

answered Aug 19 '10 at 21:18

jpluijmers

360
1
7

3

`wget` in spider mode with a correct session cookie on an private wiki was a thing I actually had to do once. Of course, one of the first crawled URLs was `/logout`. – Helgi Jul 24 '11 at 12:21
6

Try going to http://SuperLogout.com to see how destructive GET requests to `/logout` pages really are. For example, you'll have to sign in into Gmail again, sign into chat again, find your place in any Hangouts conversations you had scrolled etc. - and this is only for Google.com. – Dan Dascalescu Jan 29 '16 at 00:02
6

@DanDascalescu you should warn people that visiting this page will logout them immediately and there is no confirmation button! *very angry emoji* – Artur Nov 03 '20 at 07:05

Logout: GET or POST?

10 Answers10

Linked

Related