dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #51089
Re: API not showing 401 Unauthorized error
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/ste
p_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