dhis2-devs team mailing list archive

[Morten Olav Hansen <1388996@xxxxxxxxxxxxxxxxxx>]

Hi

We are working on this, and it should be there for the 2.18 release. We
have started the work in 2.17, but we didn't want to change output from
the web-api so late in the release process, so it will be pushed to
2.18, we will be switching to strictly following the Accept header (or
fallback to content-type header) for all input/output in the web-api,
which means /api/dataElements.json will also return error messages in
json.

We do want to also look into doing non-form login with the web-api (so
its challenged using basic), but right now spring security to support
form + basic, which  means it will redirect. If possible, this should be
changed so that requests to /api/ will use basic only (or piggyback on
form auth if it already happened).

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