dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #51090
Re: API not showing 401 Unauthorized error
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
On Tue, Apr 24, 2018 at 12:21 PM, Jason Pickering <
jason.p.pickering@xxxxxxxxx> wrote:
> 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.
> 2) In versions 2.28 and above, a 302 response is sent from the server.
>
> The API tests were developed against 2.27, and it was a 401 response sent
> by the server with basic authentication was not successful.
>
> https://github.com/dhis2/api-tests/blob/master/features/step
> _definitions/authentication.js#L38
>
> Regards,
> Jason
>
>
> On Tue, Apr 24, 2018 at 4:39 AM, Morten Olav Hansen <morten@xxxxxxxxx>
> wrote:
>
>> 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 <morten@xxxxxxxxx>
>> wrote:
>>
>>> 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 tells DHIS2 that
>>> this request is done by XHR (and not a browser), we can't change the
>>> default to 401 as it would break things badly.
>>>
>>>
>>> --
>>> Morten Olav Hansen
>>> Senior Engineer, DHIS 2
>>> University of Oslo
>>> http://www.dhis2.org
>>>
>>> On Mon, Apr 23, 2018 at 7:17 PM, Jason Pickering <
>>> jason.p.pickering@xxxxxxxxx> wrote:
>>>
>>>> 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
>>>> localhost:
>>>>
>>>> * Trying 127.0.0.1...
>>>> * TCP_NODELAY set
>>>> * Connected to localhost (127.0.0.1) port 8080 (#0)
>>>> * Server auth using Basic with user 'admin'
>>>> > GET /api/me HTTP/1.1
>>>> > Host: localhost:8080
>>>> > Authorization: Basic YWRtaW46ZGlzdHJpY3Q=
>>>> > User-Agent: curl/7.53.1
>>>> > Accept: */*
>>>> >
>>>> < HTTP/1.1 302 Found
>>>> < Server: Apache-Coyote/1.1
>>>> < X-XSS-Protection: 1; mode=block
>>>> < X-Frame-Options: SAMEORIGIN
>>>> < X-Content-Type-Options: nosniff
>>>> < Location: http://localhost/dhis-web-commons/security/login.action
>>>> < Content-Length: 0
>>>> < Date: Mon, 23 Apr 2018 12:15:22 GMT
>>>>
>>>>
>>>> On Mon, Apr 23, 2018 at 11:36 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>>> wrote:
>>>>
>>>>> 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 credentials.
>>>>>
>>>>> Regards
>>>>> Bob
>>>>>
>>>>> On 23 April 2018 at 09:46, Jason Pickering <
>>>>> jason.p.pickering@xxxxxxxxx> wrote:
>>>>> > 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/api-tests/blob/master/features/ste
>>>>> p_definitions/authentication.js#L38)
>>>>> > which also expects a 401. This is all fine, but could you provide a
>>>>> bit more
>>>>> > context on the change in behavior and whether this is expected?
>>>>> >
>>>>> > Regards,
>>>>> > Jason
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Mon, Apr 23, 2018 at 2:53 AM, Morten Olav Hansen <
>>>>> morten@xxxxxxxxx>
>>>>> > wrote:
>>>>> >>
>>>>> >> 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 <
>>>>> matavirer@xxxxxxxxx>
>>>>> >> wrote:
>>>>> >>>
>>>>> >>> 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: nginx/1.4.6 (Ubuntu)
>>>>> >>>
>>>>> >>> Date: Sat, 21 Apr 2018 13:13:18 GMT
>>>>> >>>
>>>>> >>> Content-Length: 0
>>>>> >>>
>>>>> >>> Connection: keep-alive
>>>>> >>>
>>>>> >>> X-XSS-Protection: 1; mode=block
>>>>> >>>
>>>>> >>> X-Frame-Options: SAMEORIGIN
>>>>> >>>
>>>>> >>> X-Content-Type-Options: nosniff
>>>>> >>>
>>>>> >>> Location:
>>>>> >>> https://play.dhis2.org/2.29/dhis-web-commons/security/login.action
>>>>> >>>
>>>>> >>>
>>>>> >>> HTTP/1.1 302
>>>>> >>>
>>>>> >>> Server: nginx/1.4.6 (Ubuntu)
>>>>> >>>
>>>>> >>> Date: Sat, 21 Apr 2018 13:13:18 GMT
>>>>> >>>
>>>>> >>> Content-Length: 0
>>>>> >>>
>>>>> >>> Connection: keep-alive
>>>>> >>>
>>>>> >>> X-XSS-Protection: 1; mode=block
>>>>> >>>
>>>>> >>> X-Frame-Options: SAMEORIGIN
>>>>> >>>
>>>>> >>> X-Content-Type-Options: nosniff
>>>>> >>>
>>>>> >>> Location:
>>>>> >>> https://play.dhis2.org/2.29/dhis-web-commons/security/login.action
>>>>> >>>
>>>>> >>>
>>>>> >>> HTTP/1.1 302
>>>>> >>>
>>>>> >>> Server: nginx/1.4.6 (Ubuntu)
>>>>> >>>
>>>>> >>> Date: Sat, 21 Apr 2018 13:13:18 GMT
>>>>> >>>
>>>>> >>> Content-Length: 0
>>>>> >>>
>>>>> >>> Connection: keep-alive
>>>>> >>>
>>>>> >>> X-XSS-Protection: 1; mode=block
>>>>> >>>
>>>>> >>> X-Frame-Options: SAMEORIGIN
>>>>> >>>
>>>>> >>> X-Content-Type-Options: nosniff
>>>>> >>>
>>>>> >>> Location:
>>>>> >>> https://play.dhis2.org/2.29/dhis-web-commons/security/login.action
>>>>> >>>
>>>>> >>>
>>>>> >>> HTTP/1.1 302
>>>>> >>>
>>>>> >>> Server: nginx/1.4.6 (Ubuntu)
>>>>> >>>
>>>>> >>> Date: Sat, 21 Apr 2018 13:13:19 GMT
>>>>> >>>
>>>>> >>> Content-Length: 0
>>>>> >>>
>>>>> >>> Connection: keep-alive
>>>>> >>>
>>>>> >>> X-XSS-Protection: 1; mode=block
>>>>> >>>
>>>>> >>> X-Frame-Options: SAMEORIGIN
>>>>> >>>
>>>>> >>> X-Content-Type-Options: nosniff
>>>>> >>>
>>>>> >>> Location:
>>>>> >>> https://play.dhis2.org/2.29/dhis-web-commons/security/login.action
>>>>> >>>
>>>>> >>>
>>>>> >>> HTTP/1.1 302
>>>>> >>>
>>>>> >>> Server: nginx/1.4.6 (Ubuntu)
>>>>> >>>
>>>>> >>> Date: Sat, 21 Apr 2018 13:13:19 GMT
>>>>> >>>
>>>>> >>> Content-Length: 0
>>>>> >>>
>>>>> >>> Connection: keep-alive
>>>>> >>>
>>>>> >>> X-XSS-Protection: 1; mode=block
>>>>> >>>
>>>>> >>> X-Frame-Options: SAMEORIGIN
>>>>> >>>
>>>>> >>> X-Content-Type-Options: nosniff
>>>>> >>>
>>>>> >>> Location:
>>>>> >>> https://play.dhis2.org/2.29/dhis-web-commons/security/login.action
>>>>> >>>
>>>>> >>>
>>>>> >>> curl: (47) SSLRead() return error -9806
>>>>> >>>
>>>>> >>>
>>>>> >>> This causes bug in applications that access the api for
>>>>> authentication
>>>>> >>> and I can also see how this can be used to diminish system
>>>>> performance in
>>>>> >>> general.
>>>>> >>>
>>>>> >>> Regards,
>>>>> >>>
>>>>> >>> Ranga
>>>>> >>>
>>>>> >>> On Sat, Apr 21, 2018 at 8:51 AM, Jason Pickering
>>>>> >>> <jason.p.pickering@xxxxxxxxx> wrote:
>>>>> >>>>
>>>>> >>>> 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.4.6 (Ubuntu)
>>>>> >>>> Date: Sat, 21 Apr 2018 06:44:10 GMT
>>>>> >>>> Content-Length: 0
>>>>> >>>> Connection: keep-alive
>>>>> >>>> X-XSS-Protection: 1; mode=block
>>>>> >>>> X-Frame-Options: SAMEORIGIN
>>>>> >>>> X-Content-Type-Options: nosniff
>>>>> >>>> Location:
>>>>> >>>> https://play.dhis2.org/2.29/dhis-web-commons/security/login.
>>>>> action
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> In 2.27, this same request returns a 401.
>>>>> >>>>
>>>>> >>>> curl -I -u admin:distric -H 'Accept: application/json'
>>>>> >>>> https://play.dhis2.org/2.27/api/me
>>>>> >>>> HTTP/1.1 401
>>>>> >>>> Server: nginx/1.4.6 (Ubuntu)
>>>>> >>>> Date: Sat, 21 Apr 2018 06:44:27 GMT
>>>>> >>>> Content-Type: text/html;charset=utf-8
>>>>> >>>> Content-Length: 1071
>>>>> >>>> Connection: keep-alive
>>>>> >>>> X-XSS-Protection: 1; mode=block
>>>>> >>>> X-Frame-Options: SAMEORIGIN
>>>>> >>>> X-Content-Type-Options: nosniff
>>>>> >>>> Set-Cookie: JSESSIONID=05596EBFC26A7C1843D298E98619C7FB;
>>>>> Path=/2.27;
>>>>> >>>> HttpOnly
>>>>> >>>> WWW-Authenticate: Basic realm="DHIS2"
>>>>> >>>> Content-Language: en
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On Fri, Apr 20, 2018 at 1:40 PM, Rangarirai Matavire
>>>>> >>>> <matavirer@xxxxxxxxx> wrote:
>>>>> >>>>>
>>>>> >>>>> 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 <
>>>>> morten@xxxxxxxxx>
>>>>> >>>>> wrote:
>>>>> >>>>>>
>>>>> >>>>>> 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
>>>>> >>>>>> <matavirer@xxxxxxxxx> wrote:
>>>>> >>>>>>>
>>>>> >>>>>>> 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'
>>>>> >>>>>>> https://play.dhis2.org/2.28/api/me
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> I think this behaviour should be corrected as it may lead to
>>>>> >>>>>>> unexpected behaviour of apps.
>>>>> >>>>>>>
>>>>> >>>>>>> Regards
>>>>> >>>>>>>
>>>>> >>>>>>> On Wed, Apr 18, 2018 at 11:10 PM, Rangarirai Matavire
>>>>> >>>>>>> <matavirer@xxxxxxxxx> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>> Hi Devs,
>>>>> >>>>>>>>
>>>>> >>>>>>>> I am wondering whether the behaviour I am seeing is a bug or
>>>>> >>>>>>>> something to be expected due to some change.
>>>>> >>>>>>>>
>>>>> >>>>>>>> When I run the following curl command:
>>>>> >>>>>>>>
>>>>> >>>>>>>> curl -I -u admin:distric -H 'Accept: application/json'
>>>>> >>>>>>>> https://play.dhis2.org/2.29/api/me
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> I get an HTTP 302 response. Note that I have deliberately set
>>>>> the
>>>>> >>>>>>>> password wrong so I can mock a 401 unauthorized response. I
>>>>> get the same
>>>>> >>>>>>>> response when I run the command on version 2.28. However, as
>>>>> expected, when
>>>>> >>>>>>>> I run it on 2.27, 2.26 etc I get a 401 HTTP response.
>>>>> >>>>>>>>
>>>>> >>>>>>>> I hope someone can assist.
>>>>> >>>>>>>>
>>>>> >>>>>>>> Regards,
>>>>> >>>>>>>>
>>>>> >>>>>>>> Ranga
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> _______________________________________________
>>>>> >>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>> >>>>>>> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>> >>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>> >>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>> >>>>>>>
>>>>> >>>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> _______________________________________________
>>>>> >>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>> >>>>> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>> >>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>> >>>>> More help : https://help.launchpad.net/ListHelp
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> Jason P. Pickering
>>>>> >>>> email: jason.p.pickering@xxxxxxxxx
>>>>> >>>> tel:+46764147049
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Jason P. Pickering
>>>>> > email: jason.p.pickering@xxxxxxxxx
>>>>> > tel:+46764147049
>>>>> >
>>>>> > _______________________________________________
>>>>> > Mailing list: https://launchpad.net/~dhis2-devs
>>>>> > Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>> > Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>> > More help : https://help.launchpad.net/ListHelp
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jason P. Pickering
>>>> email: jason.p.pickering@xxxxxxxxx
>>>> tel:+46764147049
>>>>
>>>
>>>
>>
>
>
> --
> Jason P. Pickering
> email: jason.p.pickering@xxxxxxxxx
> tel:+46764147049
>
Follow ups
References
-
API not showing 401 Unauthorized error
From: Rangarirai Matavire, 2018-04-18
-
Re: API not showing 401 Unauthorized error
From: Rangarirai Matavire, 2018-04-20
-
Re: API not showing 401 Unauthorized error
From: Morten Olav Hansen, 2018-04-20
-
Re: API not showing 401 Unauthorized error
From: Rangarirai Matavire, 2018-04-20
-
Re: API not showing 401 Unauthorized error
From: Jason Pickering, 2018-04-21
-
Re: API not showing 401 Unauthorized error
From: Rangarirai Matavire, 2018-04-21
-
Re: API not showing 401 Unauthorized error
From: Morten Olav Hansen, 2018-04-23
-
Re: API not showing 401 Unauthorized error
From: Jason Pickering, 2018-04-23
-
Re: API not showing 401 Unauthorized error
From: Bob Jolliffe, 2018-04-23
-
Re: API not showing 401 Unauthorized error
From: Jason Pickering, 2018-04-23
-
Re: API not showing 401 Unauthorized error
From: Morten Olav Hansen, 2018-04-24
-
Re: API not showing 401 Unauthorized error
From: Morten Olav Hansen, 2018-04-24
-
Re: API not showing 401 Unauthorized error
From: Jason Pickering, 2018-04-24