dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #33974
[Bug 1388996] Re: API returns status OK 200 on unauthorized requests
** Changed in: dhis2
Milestone: None => 2.18
** Changed in: dhis2
Assignee: (unassigned) => Morten Olav Hansen (mortenoh)
** Changed in: dhis2
Importance: Undecided => Medium
** Changed in: dhis2
Status: New => Confirmed
--
You received this bug notification because you are a member of DHIS 2
developers, which is subscribed to DHIS.
https://bugs.launchpad.net/bugs/1388996
Title:
API returns status OK 200 on unauthorized requests
Status in DHIS 2:
Confirmed
Bug description:
Requesting /api/messageConversations.json without any Authorization
header gives a status OK 200 with the HTML corresponding to a login
page. It is then hard for developers to differentiate weather or not
the request was successful or not.
An option would be to return the same data, but with a status code 401 Unauthorized.
But the problem here is that a RESTful API should not return HTML on *.json requests, and there should be very little redirecting involved.
By requesting data from one endpoint (e.g. /api/me.json), one would
assume that the response would be JSON, with either a success or an
error status. Errors should then be served in a JSON format like this
{message: "Unauthorized request"}.
Why is this a problem?
At the moment we are creating a single-page application for DHIS2 which does not reload pages from the server, and will therefore the user will never be prompted to log in when the session is invalidated.
How could one achieve these status codes by todays API?
It is possible to get 401 statuses, but then you would need to input a knowingly wrong authorization token (Basic XX). If the part after Basic is empty, you will get a response OK 200 and the login page.
However, this does not apply when you use cookie-based login. Then you will always get OK 200 as a response for every request.
To manage notifications about this bug go to:
https://bugs.launchpad.net/dhis2/+bug/1388996/+subscriptions
References