Bug #3097
closedUnintended 401 login prompt
Description
According to Mozilla [1]:
RFC 7235 defines the HTTP authentication framework, which can be
used by a server to challenge a client request, and by a client to provide
authentication information.
The challenge and response flow works like this:
1. The server responds to a client with a 401 (Unauthorized) response
status and provides information on how to authorize with a WWW-
Authenticate response header containing at least one challenge.
2. A client that wants to authenticate itself with the server can then do so
by including an Authorization request header with the credentials.
3. Usually, a client will present a password prompt to the user and will
then issue the request including the correct Authorization header.
The problem is that - in line with RFC 7235 - browsers will always pop up
a password prompt when the WWW-Authenticate header is present. This
is only useful if no javascript-based UI is handling the password prompt.
But it's not desirable in all other cases. So if the WWW-Authenticate
header was provided by the client, then it's no longer needed to re-ask for
it.
The patch should apply on Lighttpd-1.4.59.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication
Files
Updated by gstrauss over 2 years ago
- Status changed from Patch Pending to Invalid
- Priority changed from Normal to Low
- Target version deleted (
1.4.x)
So if the WWW-Authenticate header was provided by the client, then it's no longer needed to re-ask for it.
You are mistaken.
(and also mistaken with what I think you meant to say "... if the Authorization header was provided by the client ...", as your patch suggests, instead of "WWW-Authenticate")
Please quote the RFC where you think that the RFC states what you have suggested. (The RFC does not say that.)
RFC 7235 explicitly requires the opposite of your statement.
From RFC 7235 section 3.1:
"The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource."
https://datatracker.ietf.org/doc/html/rfc7235#section-3.1
3.1. 401 Unauthorized The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource. If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.
https://datatracker.ietf.org/doc/html/rfc7235#section-4.1
4.1. WWW-Authenticate [...] A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge. A server MAY generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials) might affect the response.
https://datatracker.ietf.org/doc/html/rfc7235#section-4.2
4.2. Authorization [...] If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).
Updated by ThomasDevoogdt over 2 years ago
You are right, it's part of the RFC that the WWW-Authenticate header is there. But, according to this answer, https://stackoverflow.com/a/29082416, it's also a fact that browsers are popping their logging prompt when they receive a 4xx together with such a WWW-Authenticate header.
But then, I still have the question:
“How can I suppress the browser's authentication dialog?”
(https://stackoverflow.com/questions/86105/how-can-i-suppress-the-browsers-authentication-dialog)
The only answer I could find is hacking the backend server and change the behavior (shortly, what I did here).
Can this behavior, or similar not be added using some mod_auth config variable?
Another proposal is this one: https://stackoverflow.com/a/20221330
“If the client has set the header X-Requested-With: XMLHttpRequest, the server drops the www-authenticate header in its response.”
But that one is of course not official, I know.
Updated by gstrauss over 2 years ago
You filed a bug report in the lighttpd issue tracker.
In no uncertain terms, the bug report you filed is blatantly wrong, as was already pointed out.
RFC 7235 explicitly requires the opposite of your statement.
From RFC 7235 section 3.1:
"The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource."
Period. End of story. End of discussion in this invalid bug report. Not ifs, ands, or buts.
If you have client-side questions or client-side problem, then an invalid bug report in the lighttpd issue tracker is most certainly not the place to try to continue that discussion. The lighttpd issue tracker is for issues in lighttpd, not user questions. You might post to the lighttpd user forums (see "Forums" tab at top of page), but those are still aimed at server-side, not client-side problems, so I think you would do better to ask in a client developer forum somewhere else.
Another proposal is this one: https://stackoverflow.com/a/20221330
“If the client has set the header X-Requested-With: XMLHttpRequest, the server drops the www-authenticate header in its response.”
But that one is of course not official, I know.
When an RFC uses the word "MUST", there is no room for debate in that piece of the implementation. Also, while you might use stackoverflow as a reference for ideas, in general, I caution you strongly against using stackoverflow as an authoritative source. It does not bolster your flimsy arguments.
The only answer I could find is hacking the backend server and change the behavior (shortly, what I did here).
Can this behavior, or similar not be added using some mod_auth config variable?
<facepalm> Such behavior absolutely will not be added. I am going to cease responding here. You have no idea how foolish you sound.
You can implement your own custom flagrant-violations-of-the-RFC for auth using mod_magnet, e.g. mod_magnet lua examples, or using mod_fastcgi authorizer mode.
.
If the above is not worded strongly enough, let me be clear: if you post further in this invalid bug report, your posts here may be deleted.
Updated by gstrauss over 2 years ago
For others who might find this ticket:
lighttpd documents that lighttpd mod_auth implements HTTP Auth methods:
lighttpd mod_auth natively supports authentication methods:
(The documentation was recently modified to further highlight this, but the wiki history shows this was previously documented, too)
Regarding this ticket, lighttpd mod_auth will not be modified to violate MUST directives from RFC7617 or RFC7616.
Independently, lighttpd provides other ways for an admin to configure lighttpd.conf in order to manipulate request and response headers, e.g. with mod_setenv or mod_magnet. These manipulations are whatever you define, and are RFC-compliant if you configure them to be compliant, or can violate the RFCs if you configure them to violate the RFCs.
lighttpd also allows custom authentication and authorization to be implemented by the admin, separately from lighttpd mod_auth, through the use of custom mod_fastcgi authorizer scripts, or via custom mod_magnet lua scripts. "Custom authentication and authorization" is defined to be whatever you want it to be. It could be HTTP Bearer Auth. It could be something which violates RFC7617 HTTP Digest Auth or RFC7616 HTTP Basic Auth. It could be whatever you want it to be, but it will not be lighttpd mod_auth.
Also available in: Atom