Basic Auth module conflicts with server-level "Site Lock" implementations

Tagging for the Bug Smash Initiative.

I ran into this as well and the patch in #57 fixed it. I'm on Drupal 9.5.8.

The solution from #57 still works fine on Drupal 10.2. Is there any reason not to (reroll and) commit this?

This was discussed at a Bug Smash meeting yesterday with larowlan, dsci, and pameeela. The conclusion was that this is a feature request. The issue summary took a while to understand so adding the tag for an IS update.

@dsci plans to come back to this issue later this week and do triage. Let's hope that happens.

Updated IS to make the use case a bit more clear, but it probably still needs further updates.

Discussing in Slack we are not sure this is a bug, as even the OP concedes.

carlos romero → made their first commit to this issue’s fork.

carlos romero → closed merge request !9678

As described in #70, the patch in #57 works for us with Drupal 10.3.5, it would be great if this issue is going further in progress.

prudloff → changed the visibility of the branch 10.4.x to hidden.

prudloff → changed the visibility of the branch 10.3.x to hidden.

prudloff → changed the visibility of the branch 2842858-basic-auth-module to hidden.

I think #24 is a valid concern (see 🌱 [policy] Treat username enumerations as security bugs that require Security Advisories Active ).

Updated issue summary with plans to move forward with this.

codebymikey → changed the visibility of the branch 11.x to hidden.

Added the username check on the basic auth prompt (hidden behind a setting) and a simple test case for it.

> The basic auth provider will only act upon routes which have been explicitly tagged with the basic_auth _auth option.

If basic_auth is enabled, and basic auth is received on a route that is *not* tagged for basic auth, should we log or display a warning message?

> The basic auth provider will only act upon routes which have been explicitly tagged with the basic_auth _auth option.

If basic_auth is enabled, and basic auth is received on a route that is *not* tagged for basic auth, should we log or display a warning message?

That's an accidental entry to the issue summary, and actually meant for the 🐛 Basic auth returns 403 when username & password supplied but not needed. Needs work issue.

The changes so far only check for the username's existence.

But no, I don't think it's worth logging it as modules making use of basic_auth should already be tagged as such, and bad actors can use this as a means of filling up the logs without suffering the penalty of being banned by the flood control system.

Instead of having a settings.php entry, how about a submodule, e.g. "Basic Auth with Site Lock" (the name probably needs work) - this would act as the flag instead? The module description can explain why you might want this enabled if you are using Basic Auth.

Instead of having a settings.php entry, how about a submodule, e.g. "Basic Auth with Site Lock" (the name probably needs work) - this would act as the flag instead?

The feature flag module idea is interesting, but seems like potential overhead (haven't benchmarked how expensive calls to the module handler checks are) for a feature that most sites would probably rarely need.

I took inspiration with how the phpinfo() status page behaviour → was changed, and the setting seemed like the way to go for a functionality tightly coupled with the site's security.

However if that's the convention going forward for core to make it easier for non-technical people to work with it, then I have no objection.

Would need input from members on the core team to provide further direction on this.

Yeah, it's never been clear to me where this sort of thing should go. Right now we have an awkward combination of:

• $settings array in settings.php
• $config array in settings.php
• config form with a UI
• container parameter in services.yml
• feature flag module
• some new API? ✨ Add an API for feature flags Active

Also ideally it wouldn't be a moduleExists() check, instead the code to handle this feature would live self-contained in the contrib module, extending basic_auth as necessary.