It's also documented here so if this behavior really has changed and this
is not a bug, we need to change the docs as well:
https://docs.dhis2.org/master/en/developer/html/webapi_
system_resource.html#d0e12069
JIRA issue here:
https://jira.dhis2.org/browse/DHIS2-3519
On Tue, Apr 24, 2018 at 10
I think maybe its related to openldap, there was some issues with our ldap
configuration a while back
Please file a jira issue for it, and I will have Viet have a look at it (at
least we can confirm the reason)
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
Hi Morten,
All of the information is provided in this thread. What both Ranga and I
are saying is that when authenticating with basic authentication, and the
authentication is not successful the following behavior is seen
1) In versions below 2.27 and below, a 401 response is sent from the
server.
In what version did this return a 401? because that sounds like a bug to
me.. if you give me the version number, I can have a look
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Tue, Apr 24, 2018 at 9:38 AM, Morten Olav Hansen
wrote:
> I'm not sure exa
I'm not sure exactly what you mean Jason, this has been like this always?
Are you saying this behavior has changed? because it should not have. To
make the browser properly redirect to the login page, it needs to send a
302 to forward it.
In 2.28 we introduced the X-Requested-With header which tel
Hi Bob,
Yeah,I am not sure its fine either but what I am trying to get information
on is what the expected behavior actually should be. Seems it should not be
this though from what you and Ranga are saying. Just to exclude any
possible effect from the reverse proxy, its the same against a localho
Hi Jason
I am not sure that this is all fine. It looks to me like this is a
bug which has slipped in and that the original 401 response is the
correct expected behaviour. API users using pre-emptive basic
authentication have no good reason to be redirected to the login page
with invalid credenti
Hi Morten,
I am going to persist here, as its still not clear to me what has changed
in the API.
Ranga documents that the API behavior has changed when trying to access
/api/me with basic authentication. It has changed from a 401 to a 302. This
also breaks the API tests (
https://github.com/dhis2
Try and set the header "X-Requested-With" to "XMLHttpRequest"
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Sat, Apr 21, 2018 at 8:19 PM, Rangarirai Matavire
wrote:
> Thanks Jason,
>
> In addition, if you add the '-L' option to the 2.28 and 2.29 queri
Thanks Jason,
In addition, if you add the '-L' option to the 2.28 and 2.29 queries as
follows:
curl -I -L -u admin:distric -H 'Accept: application/json'
https://play.dhis2.org/2.29/api/me
You get a redirect loop which seems infinite until it terminates in error
as follows:
HTTP/1.1 302
Server:
Just to try and make it a bit more clear Morten, I think this is the issue
Rangarai is asking about is below:
In 2.29 and 2.28, an unauthorized username/password returns a 302.
curl -I -u admin:distric -H 'Accept: application/json'
https://play.dhis2.org/2.29/api/me
HTTP/1.1 302
Server: nginx/1.
Hi Morten,
The password is set wrong deliberately so as to get a 401 or other
response. The problem is when you set the wrong password or username you
get endless redirects from the API.
Regards,
On Fri, Apr 20, 2018 at 1:24 PM, Morten Olav Hansen
wrote:
> It should be district, not distric..
It should be district, not distric... but also people keep changing our
internal passwords (our database resets every 24 hour)
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Fri, Apr 20, 2018 at 12:09 PM, Rangarirai Matavire
wrote:
> By the way, its no
By the way, its not just the error response code that is worrying, but also
the loop of redirects that starts, this makes it difficult to handle the
response for an http client. To see this loop of redirects, you can add -L
to curl as below.
curl -I -L -u admin:distric -H 'Accept: application/json
14 matches
Mail list logo
