Why is login a get method whereas logout is a post?

[barakbd]

Issue Description

The API method for Login is GET. Why isn't is a post with a body?
The API method for logout is POST, but nothing is sent in body (only session token in header)

[flovilmart]

Is that an issue?

[barakbd]

It just seems wrong.
I am wondering what is the reason for this design.

[montymxb]

@barakbd This has actually been bugging me a bit too to be honest. Logout aside the login over GET is not necessarily insecure, but it could be better. The existing method of using GET to login is generally safe client side when the connection is secured via TLS/SSL.

However, one of my primary concerns is that once a request arrives server-side the situation can change. If you're passing through a proxy or are piping the output directly into a log file (which you should not do, as there is built in logging that sanitizes those fields) you might end up storing those sensitive values in your logs. If you're in control of the instance you can always make sure to avoid that, but it's still a potential pitfall. If you're running through a service or proxy you do not control then it becomes a bit more of a concern.

Beyond that it's fine to use, as 'wrong' as GET may seem, it is just another method under REST, the primary concern being whether the connection is secure overall or not. Considering that the major difference is mostly in how it's respected versus POST, especially in browsers, it's just another method to perform requests via.

As for the reason it was designed I'm not not entirely certain who decided on that, but it is in place now, and the SDKs expect GET for login. Personally, if it was redesigned I think it would be better if it were POST, but that's not the case.

If you have any particular qualms with it I would encourage you to provide us with a condition of where it is wrong, versus where it feels wrong. If we have something solid that can be demonstrated and is a reasonable concern we'll move to correct it 👍 . Might I recommend if you do find something that could be considered a security concern that you should contact us privately so that we may address such an issue safely, without encouraging others to exploit it themselves.

[markmssd]

Amen!

[c3s4r]

Using GET for login do is insecure, even over https. The reason? The username and password will be transferred as part of the URI. Not only this can be cached in the browser history, but it will be cached / logged also on any proxy server that the request goes through.

See https://stackoverflow.com/questions/26671599/are-security-concerns-sending-a-password-using-a-get-request-over-https-valid

I wouldn't like to send my password knowing that an IT guy can see it in the squid proxy server that we have installed in my company, and that can be logged in any server / router that the request goes through.

EDIT: After some research I found that I was wrong on the striked out statements. (see my comment below).

[natanrolnik]

@c3s4r and using a proxy server he wouldn't be able to see it in the request's body?

[c3s4r]

@natanrolnik after doing some more research I'm editing my comment. It looks like the query string won't be visible in the proxy if using https. The problems of having parameters in the URL actually are:

• leakage through browser history
• leakage through the http referrer when visiting another page (I think it doesn't apply since the API returns JSON and not an HTML page)

I guess I still should be concerned about the first, specially when connecting to parse server from a single page javascript app.

Use case I login to my parse app using a single web app (e.g. react, angular) from a public computer. The history of requests will still be saved in the browser history, won't be?

[montymxb]

So this has been on my mind a bit, although we can't remove the existing functionality I was wondering if we could offer POST in addition to GET. The idea being deployed sdks would work just fine, and new ones could be updated to utilize POST over GET. It looks like this is all we would need to adjust.

Looking at some of lines above you can see...

this.route('GET', '/users', req => { return this.handleFind(req); });
this.route('POST', '/users', req => { return this.handleCreate(req); });

Same route, different method, different callback. Perhaps we could modify login to do something similar, but with the same callback.

this.route('GET', '/login', req => { return this.handleLogIn(req); });
this.route('POST', '/login', req => { return this.handleLogIn(req); });

The change would be minimal, but if it works we could start shifting the method the sdks use for login. It would require the target server to be up to date, and once changing the login method in an SDK it would be unusable with any out of date servers.