Cannot log into site after installation

A *huge* thanks to @tim.plunkett putting me on the right path. I finally figured out the cause of the issue (though I think there is more need of a resolution hence changing to a bug report). In my scenario, since it was on a public server, we had placed the site behind basic authentication by apache. From the Drupal side, Drupal has a pluggable authentication system and it comes with 2 of them out of the box: HttpBasic and Cookie.

D8 attaches both the HttpBasicauth and Cookie authentication providers to the system (runs in order of HttpBasic followed by Cookie). Within the queue, if any auth passes, it breaks out of the loop and continues. In this case, since HttpBasic runs first and passes, it doesn't get around to Cookie (which actually adds session.inc) and thus, it fails in the end.

Ultimately user_login_finalize requires for a session to be present. So it seems like Cookie needs to have the highest priority and run first or each of the providers need to include session.inc. I can foresee dev sites (not just mine!) being password protected so suggestions on how to approach a patch would be very helpful.

That is certainly a much simpler solution than including line in every authentication provider :)

For testing...I was trying to figure out an appropriate way to test something like this within simpletest. We do technically have access to http://php.net/manual/en/features.http-auth.php so I'm assuming we would have a subscriber that adds the authentication to every page that it can pass through (though how well it plays with existing tests is another issue entirely).

In any event, I just tried out the patch. While the WSOD is now gone (yay!), authentication technically passed due to HTTPBasic (and HTTPBasic may just be a simple user/pass to access the site). As a result, it never gets around to Cookie which would do a proper check via the user login form and thus the user does not get logged in.

Looking through the implementation of this, I see the HttpBasic has a priority of 100 while Cookie has a priority level of 0. As a result, HttpBasic would run first at part of the authentication chain (though it isn't exactly a chain as checking which auth rules apply boils down to which auth provider passes first). Which...leads me to a few questions.

I'm going to give an example of the LDAP module for D6/D7. It has a bypass check for user 1 whereby it will use any other Drupal-based authentication (instead of ldap) when dealing with the superuser. All other users have the option to only get checked via both Drupal/Ldap or just ldap.

In D8, it doesn't seem like those would really be possible (atleast at a first glance). We either need to have extra rules (as in applies if we were dealing with ldap) or figure out how to have a proper chain to check through all authentication providers (or not. maybe this makes less sense).

In any case, one possible approach I see atleast around this issue is to actually make the HttpBasic provider become part of a new core module that implements the same class (or move it out to contrib). It doesn't need to be running on every site automatically and people enable the module if they need to.

@Crell, thank you for pointing me towards that issue - I've issued a patch in there for a faster resolution (of that task).

With that said (and before we close this issue closed out for either being a duplicate or by design), I have a few questions to go with all of this: How should a system where we (can) have multiple authentication systems (we have two in core and will have several others in the future) behave? Is the Drupal authentication system chainable? And why (regardless of answer)?

Thanks for the explanation - it sounds fairly reasonable to me (along with others that I've talked with that implement their own auth backend.