It looks like it was decided to send the WWW-Authenticate header for every invalid_client error, probably in the hope to satisfy that "RFC 6749, section 5.2"
However this is causing some very mysterious behaviour for the other invalid_client possible errors.
In particular in Laravel Passport if you misconfigure the redirect URL, you end up with Basic auth login popups firing and no useful error messages https://github.com/laravel/passport/issues/340
I'm unfamiliar with this RFC but I believe the case would be better uncovered than covered like this. Plus it looks like it's not enough #738
By the way you skipped test coverage on that code, so I think we can safely tell it's messy :disappointed:
I think we should verify if request contains Authorization header field :
if (array_key_exists('HTTP_AUTHORIZATION', $_SERVER) !== false){
// Add "WWW-Authenticate" response header field
}
We are suffering with this problem too.
@ravanscafi for my part, I removed manually this unexpected header on my authorization controller :
catch (OAuthServerException $exception) {
return $exception->generateHttpResponse($response)->withoutHeader('WWW-Authenticate');
}
I've started working on a fix for this and will hopefully close it out this evening. @benito103e is correct in that we should only be adding this header if the _authorization_ header has been used.
I want to do a bit more investigation beforehand though. By changing this so that the header is only issued when you have an authorization header in the request, it might not solve your specific use-case.
We sometimes use the redirect_uri to identify the client so an incorrect redirect_uri _might_ still issue this behaviour but this depends on if the authorization header is present. I will double check this this evening and get back to you all.
Most helpful comment
I've started working on a fix for this and will hopefully close it out this evening. @benito103e is correct in that we should only be adding this header if the _authorization_ header has been used.
I want to do a bit more investigation beforehand though. By changing this so that the header is only issued when you have an authorization header in the request, it might not solve your specific use-case.
We sometimes use the redirect_uri to identify the client so an incorrect redirect_uri _might_ still issue this behaviour but this depends on if the authorization header is present. I will double check this this evening and get back to you all.