The Basic Authentication module lets requests be authenticated by providing basic authentication headers in the requests. While this is meant to be used for rest services, it works for any kind of requests, and any request with headers will be intercepted and validated.
If you activate the basic auth module and deploy that change to an environment that is protected with .htaccess (I'm calling it this so we know which one is which) - which is quite common for any dev / staging environments - every request will have authentication headers for the .htaccess protection that the module will try to validate, and unless the credentials match a drupal user each request will result in a 403 response. This even affects pages that are always accessible, like /filter/tips.
There is no hint at what could be causing this (it took some time to figure that out). Most browsers will keep sending the headers even if the .htaccess protection has been removed, causing further confusion.
We probably can't prevent this behaviour, but we should inform the user of what is going on. How about displaying a message like "The HTTP Basic Auth credentials you submitted are not valid" on HTML responses when the basic auth validation fails?
Comments
Comment #2
Bart Vanhoutte CreditAttribution: Bart Vanhoutte at Duo commentedI can confirm the symptoms, although I have a slightly different use case. I want to use HTTP Basic Authentication in a custom module of mine. To keep stuff DRY I want to depend on the basic_auth module to do all the hard (flood) stuff. When enabling both the custom module and basic_auth all pages return a 403.
Moreover, when looking at
\Drupal\basic_auth\PageCache\DisallowBasicAuthRequests
it says thatThe code only checks the current request's headers for PHP_AUTH_USER and PHP_AUTH_PW, it does not check whether the current route is using basic_auth as authentication provider. This will disable page caching on all routes when a different module implements HTTP Basic Authentication.
When reading the documentation (quote) you can assume that it will only disable cache for routes that use basic_auth.
Comment #3
BerdirI have no idea how we could fix this.
basic_auth couldn't actually possibly work (you can't have multiple basic auth layers) but I can see that you don't care about that on dev/staging servers (still, that implies that you are not/can not test your basic auth protected functionality there).
Similar for caching. That check happens *way* earlier than authentication, at that point we don't know if that will be successful and checking that would be quite a bit of overhead.
Comment #5
eugene.ilyin CreditAttribution: eugene.ilyin as a volunteer and at DrupalJedi commentedI had the same trouble and after debugging I found that if basic_auth would be global provider, then filter would be successfully applied and request will be passed. What actually the difference between global and not global authentication providers? I have tried to google about it, but didn't found anything.
Comment #6
IT-CruSame problem here when using a PHP basic auth in settings.php on acquia DEV / STAGE environments and then other modules require D8 core basic_auth module. When disable PHP basic auth in settings.php site works again after re-deploy, drush cr and varnish clear on acquia cloud, but I think this should not a final fix for this issue.
Comment #9
sylvain lavielle CreditAttribution: sylvain lavielle commentedSame problem here
Comment #10
Jose Reyero CreditAttribution: Jose Reyero at Axel Springer España commentedHi, I've just found this one too.
Though I don't know too much about basic auth, I'm wondering:
Since the most common use case for basic auth seems to be services (which is mine too), couldn't we provide an option (that may be a hidden setting or similar, doesn't need UI) to restrict Drupal's basic auth to some path/s and or request types?
If possible, that should allow us to use it for services while also using a different basic auth for other paths / requests (login into dev environments, etc..)
Comment #11
Wim LeersThis is a duplicate of #2842858: Basic Auth module conflicts with server-level "Site Lock" implementations. Yes, this one existed for longer. But the other one has far more discussion, and patches.