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

floretan created an issue. See original summary.

Bart Vanhoutte’s picture

I 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 that

This policy disallows caching of requests that use basic_auth for security reasons...

The 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.

Berdir’s picture

I 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.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

eugene.ilyin’s picture

I 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.

IT-Cru’s picture

Same 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.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

sylvain lavielle’s picture

Same problem here

Jose Reyero’s picture

Hi, 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..)

Wim Leers’s picture

Status: Active » Closed (duplicate)
Related issues: +#2842858: Basic Auth module conflicts with server-level "Site Lock" implementations

This 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.