[PP-1] Disable CSRF token check for non-CSRF vulnerable authentication providers

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

A similar logic is happening on the CSRF header access check - it simply tests whether there's a session loaded (presumably) as the result of cookie usage.

https://git.drupalcode.org/issue/drupal-3343031/-/blob/175c46afabb6cfdb1...

I think the same criticism as I cited above regarding "...we need a service which keeps track of which authentication provider was *actually* used for the current request..." applies to that test, as well.

I agree with much of the analysis in #26, particularly:

I think to solve this properly, we need a service which keeps track of which authentication provider was *actually* used for the current request, and then the CSRF access check can use that service to be *sure* about what is actually going on during this request and only fire if the session cookie is not only present but also actively being used to authenticate the user.

I just would like to add that watch out with a solution like this, do not make the system more dependent on state as it is currently, because that is going to work against us to solve #2218651

I just would like to add that watch out with a solution like this, do not make the system more dependent on state as it is currently

I get where you're going and have been active on that linked issue, however if the information is on the request, I think that's totally compatible with persistent servers. Authentication providers are authenticating a particular request, and so storing this information there should not poison anything else.

super! :)

and so storing this information there should not poison anything else.

+1

The key_auth module got the same problem. https://www.drupal.org/project/key_auth/issues/3174961 →