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.
- 🇺🇸United States bradjones1 Digital Nomad Life
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.
- 🇭🇺Hungary mxr576 Hungary
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
- 🇺🇸United States bradjones1 Digital Nomad Life
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.
- 🇭🇺Hungary mxr576 Hungary
super! :)
and so storing this information there should not poison anything else.
+1
- 🇬🇧United Kingdom shenzhuxi
The key_auth module got the same problem. https://www.drupal.org/project/key_auth/issues/3174961 →
- 🇨🇳China lawxen
I got this problem
The comment by Wim Leers on #7 ✨ [PP-1] Disable CSRF token check for non-CSRF vulnerable authentication providers Needs work helped me find the root cause: Send jwt(Bearer token) and Basic Auth together. Thanks @Wim LeersRemove Basic Auth and restart my postman, error disappeared.