Authentication strategy for servers, which do not return a 401 on unauthenticated requests

nsIHttpChannel is usually doing an unauthenticated request to a remote URL to get the WWW-Authentication header from the 401 response and then pick one of the allowed methods to authenticate.

I am running into an issue, where the server is not returning a 401 but actually returns a result for anonymous access (even though the URL points to a /user/xy/ resource).

What is the strategy to enforce authentication? I do not want to manually add a Basic Auth header, as I want nsIHttpChannel to do all the auth stuff.

What can I do?
0
john
9/10/2019 1:15:14 PM
mozilla.dev.platform 6561 articles. 0 followers. Post Follow

8 Replies
9 Views

Similar Articles

[PageSpeed] 29

Hi,

adding a custom `Authentication` request header is the right way to do 
this.  Not sure what you mean by "I want nsIHttpChannel to do all the 
auth stuff" when it doesn't know it has to authenticate to the site.  We 
need a 401 response to produce and cache `Authentication` request 
headers based on name+password credentials.  If you were in C++ it would 
not even be enough to precache the name/password using [1], because we 
will not look it up until a 401.

-hb-

[1] 
https://searchfox.org/mozilla-central/rev/250f5cc9fb8bdcbb6b23d2a06acfd48addb2f99b/netwerk/protocol/http/nsIHttpAuthManager.idl#99


On 2019-09-10 15:15, john.bieling--- via dev-platform wrote:
> nsIHttpChannel is usually doing an unauthenticated request to a remote URL to get the WWW-Authentication header from the 401 response and then pick one of the allowed methods to authenticate.
>
> I am running into an issue, where the server is not returning a 401 but actually returns a result for anonymous access (even though the URL points to a /user/xy/ resource).
>
> What is the strategy to enforce authentication? I do not want to manually add a Basic Auth header, as I want nsIHttpChannel to do all the auth stuff.
>
> What can I do?
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

0
Honza
9/10/2019 1:34:16 PM
Thanks for your reply. 

I do not want to manually add a `Authentication` request header, as I also do not know what methods are allowed without having seen the WWW-Authentication header (and just trying basic auth is not an option for me). 

I was hoping there was some established mechanism to force the server to send that header, without sending wrong credentials on purpose.

It looks like there is nothing I can do. 
0
john
9/10/2019 1:45:39 PM
On 2019-09-10 15:45, john.bieling--- via dev-platform wrote:
> Thanks for your reply.
>
> I do not want to manually add a `Authentication` request header, as I also do not know what methods are allowed without having seen the WWW-Authentication header (and just trying basic auth is not an option for me).
>
> I was hoping there was some established mechanism to force the server to send that header, without sending wrong credentials on purpose.
>
> It looks like there is nothing I can do.

I'm afraid there is not, but that is from the nature of how HTTP auth 
works.

Do you control the server?  How is it actually expected for browsers to 
know there is a different content behind authentication when no 401 
challenge has not been received from the server?  Does the server reply 
with `Vary: Authorization` at all?  Is there some login path/address on 
the server you query to authenticate?  Any other custom request header 
you can add to the request to force a 401 response to start the 
authentication?

-hb-

> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

0
Honza
9/10/2019 2:16:56 PM
No, the server is not controlled by me. The admin expects clients to send a Basic Auth header without having seen the WWW-Authenticate header, if I do not want to access the resource unauthenticated.

For me this looked wrong from the beginning, but just wanted to make sure I am not missing anything.

I there an established header I could send, to enforce the return of WWW-Authenticate header? If so, I would forward that info to the admin for him to implement, otherwise I would call this done.
0
john
9/10/2019 2:50:13 PM
Alternatively, the admin wants me to send a bogus authenticate header, like Authenticate: X to trigger the authentication. 

I really do not like that. Maybe I can get him to jump into the discussion.
0
john
9/10/2019 2:56:18 PM
There is no official or standardized way to "force" authentication, 
because this is really a non-standard thing you do.

I would more suggest a login request path like 
"https://foo.com/login.php" or whatever scripting is used, that would 
return 401 with the challenge response header. Authenticating to it 
would simply make firefox remember that for any request to a resource at 
`https://foo.com/` we have to send the Authorization header.  This would 
be session-only, on restart you would have to do this again.

Other option is to add a custom header to the request, like 
`X-Force-WWW-Auth: 1` or whatever X- prefix you see fit.

Please keep in mind the `Vary: Authorization` response header too.

-hb-

On 2019-09-10 16:56, john.bieling--- via dev-platform wrote:
> Alternatively, the admin wants me to send a bogus authenticate header, like Authenticate: X to trigger the authentication.
>
> I really do not like that. Maybe I can get him to jump into the discussion.
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

0
Honza
9/10/2019 4:18:50 PM
Hello,

the use case is: A WebDAV (CalDAV/CardDAV) server offers:
* calendars for authenticated users
* calendars for unauthenticated users
* the bootstrapping procedure described in RFC 6764.

So the server returns one set of availabe calendars (caldav collections) fo=
r unauthenticated user, and a super set of available calendars (caldav coll=
ections) for authenticated users.  But it never returns 401 Authenticate er=
ror, as long as an unauthenticated user does not do PUT.

With this scenario the user must know, whether it wants to authenticate or =
not from the beginning, and the webdav client has to enforce what the user =
wants, before seeing 401 (as it will never be sent).

Cf. https://github.com/jobisoft/DAV-4-TbSync/issues/106 .

The way to get the set of offered authentication schemas is to send an inva=
lid user:
curl -D- -uf@example.net:a -XPROPFIND https://mail.aegee.org/dav/addressboo=
ks/

then the server returns WWW-Authenticate with the supported mechanisms.

Regards
  =D0=94=D0=B8=D0=BB=D1=8F=D0=BD
0
dilyan
9/10/2019 8:24:47 PM
Hello,

On Tuesday, 10 September 2019 16:19:01 UTC, Honza Bambas  wrote:
> There is no official or standardized way to "force" authentication,=20
> because this is really a non-standard thing you do.

Can you ellaborate on this and why is it off-standard?  What shall have bee=
n written in the standards, in order to support this use-case?

RFC 7235 says =E2=80=9CA user agent that wishes to authenticate itself with=
 an origin server -- usually, but not necessarily, after receiving a 401 (U=
nauthorized)  -- can do so by including an Authorization header field with =
the request.=E2=80=9D

So if the user insists to authenticate, the server does not have to reply w=
ith 401.  The way to get the supported schemas, apart from sending an inval=
id username with random password, is to make an OPTIONS call (on my server,=
 which happens to be also semi-standard):

curl -D-  -XOPTIONS https://mail.aegee.org/dav

HTTP/2 200=20
content-length: 0
cache-control: no-cache
www-authenticate: Basic realm=3D"AEGEE.ORG"
www-authenticate: Negotiate
allow: OPTIONS, GET, HEAD

Now, is the problem in the core of firefox/thunderbird, in the standards, i=
n the sevrer or in the addon?  In particular, does the core really refuse t=
o deal with the authentication once the addon inserts an Authentication hea=
der?  This makes it practically impossible to switch later to Negotiate: GS=
S-SPNEGO after inserting a fake Authentication header, as doing this negoti=
ation for an addon is way too much.

Regards
  =D0=94=D0=B8=D0=BB=D1=8F=D0=BD
0
Dilyan
9/13/2019 5:22:34 PM
Reply: