Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
Hello, On Tuesday, 10 September 2019 16:19:01 UTC, Honza Bambas wrote: > There is no official or standardized way to "force" authentication, > because this is really a non-standard thing you do. Can you ellaborate on this and why is it off-standard? What shall have been written in the standards, in order to support this use-case? RFC 7235 says “A user agent that wishes to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) -- can do so by including an Authorization header field with the request.” So if the user insists to authenticate, the server does not have to reply with 401. The way to get the supported schemas, apart from sending an invalid 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 content-length: 0 cache-control: no-cache www-authenticate: Basic realm="AEGEE.ORG" www-authenticate: Negotiate allow: OPTIONS, GET, HEAD Now, is the problem in the core of firefox/thunderbird, in the standards, in the sevrer or in the addon? In particular, does the core really refuse to deal with the authentication once the addon inserts an Authentication header? This makes it practically impossible to switch later to Negotiate: GSS-SPNEGO after inserting a fake Authentication header, as doing this negotiation for an addon is way too much. Regards Дилян ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
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) for unauthenticated user, and a super set of available calendars (caldav collections) for authenticated users. But it never returns 401 Authenticate error, 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 invalid user: curl -D- -u...@example.net:a -XPROPFIND https://mail.aegee.org/dav/addressbooks/ then the server returns WWW-Authenticate with the supported mechanisms. Regards Дилян ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
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
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
