CSRF check always fails for users without a session

I'd think this would count as a feature request?

I'm not looking for a fight either :) I changed the issue to 8.2.x because I thought issues were supposed to be fixed in the newest active branch and then backported as appropriate? But I might have misunderstood how the 8 branches were working, so apologies if I was wrong in that.

And ok, I concur it's a bug.

+++ b/core/lib/Drupal/Core/Access/CsrfAccessCheck.php
@@ -54,7 +61,7 @@ public function access(Route $route, Request $request, RouteMatchInterface $rout
+    if ($this->account->isAnonymous()  || $this->csrfToken->validate($request->query->get('token'), $path)) {

This should have a comment like "CSRF token checking is only useful for authenticated users because an attacker can always spoof an anonymous request themselves."

Hm, but now that I think of it: this is not depending on an authenticated user but on a session cookie. Instead of checking for an authenticated user we should check for an active session.

Then the comment should be "CSRF token checking is only useful for requests with an active cookie session because an attacker can always spoof an anonymous request themselves."

I can only think of HTTP basic auth as other authentication system that is CSRF exploitable in a browser. OAuth requires additional HTTP headers or URL tokens. HTTP Basic auth is quite an edge case and not sure we should support that here. But ok, let's check for an authenticated user as you did.

My point is that the CSRF protection should also work for anonymous users that have an active session. Example: I have a commerce cart as anonymous user and there is a link to add items to my cart. Of course I don't want an attacker tricking me into adding more stuff to my cart. That should be CSRF protected.

So we could check for

if (($this->account->isAnonymous() && session_not_active()) || $this->csrfToken->validate($request->query->get('token'), $path)) {

Replace session_not_active() with whatever session service calls.

That would have the benefit of supporting active sessions with anonymous users, which is a use case for Drupal sites.

I don't think CSRF checking for anonymous users is necessarily pointless; with or without a session cookie there are situations where it makes sense (see #1803712: Allow form tokens to be used on anonymous forms in some cases).

But since the form API completely skips CSRF checking for anonymous users already (that's still true right?) it seems OK to me to do exactly the same thing for links, then repurpose the above issue to be about adding it (back) to both of them.

I can't think of any reason why links need to have more CSRF protection than forms do in the case of an anonymous user with a session. (Unless you're saying that since links already have more CSRF protection now, it's best to remove as little of that as possible in a stable release?)

Regarding a code comment, maybe just use something similar to what the form API does? http://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Core/Form/FormBui...

By the way, I think this is supposed to be filed against 8.1.x to be considered for 8.1.x (https://www.drupal.org/core/backport-policy). (Yes, it's backwards from how everything else works where you file/work on the issue for the newest version that it applies to, but I guess it has something to do with the cherry-picking...) I am not sure if it would make it into 8.1.x though.

OK, consistency with the form system makes sense.

So the patch only needs a comment, otherwise looks good to me.

1. +++ b/core/lib/Drupal/Core/Access/CsrfAccessCheck.php
   @@ -54,7 +61,7 @@ public function access(Route $route, Request $request, RouteMatchInterface $rout
   +    if ($this->account->isAnonymous()  || $this->csrfToken->validate($request->query->get('token'), $path)) {
   

   2 spaces before "||". And the comment is missing why we check for the anonymous user.

2. +++ b/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php
   @@ -19,20 +20,26 @@ class RouteProcessorCsrf implements OutboundRouteProcessorInterface {
   +    if ($route->hasRequirement('_csrf_token') && $this->account->isAuthenticated()) {
   

   Should also have a comment why we bypass the check for anonymous users.

3. +++ b/core/modules/system/src/Tests/Common/UrlTest.php
   @@ -43,6 +44,7 @@ function testLinkXSS() {
   +    \Drupal::currentUser()->setAccount(User::load(1));
   

   Should have a comment like "Set an authenticated user to make CSRF protected links work. @see RouteProcessorCSRF"

4. +++ b/core/tests/Drupal/Tests/Core/Access/CsrfAccessCheckTest.php
   @@ -31,24 +31,34 @@ class CsrfAccessCheckTest extends UnitTestCase {
   +    $this->account = $this->getMock('Drupal\Core\Session\AccountInterface');
   

   Should use ::class syntax.

5. +++ b/core/tests/Drupal/Tests/Core/Access/CsrfAccessCheckTest.php
   @@ -65,6 +75,24 @@ public function testAccessTokenPass() {
   +   * Tests the access() method for anonymous users.
   

   Should have @covers

+++ b/core/tests/Drupal/Tests/Core/Access/RouteProcessorCsrfTest.php
@@ -77,9 +87,30 @@ public function testProcessOutbound() {
+    $bubbleable_metadata = new BubbleableMetadata();
+    $this->processor->processOutbound('test', $route, $parameters, $bubbleable_metadata);
+    $this->assertEmpty($parameters);
+    $this->assertEquals((new BubbleableMetadata()), $bubbleable_metadata);

Hm, I think we should mock $bubbleable_metadata and assert that the addAttachments() method is never called.

Th patch looks good, beside the points outlined by klausi.

The central question I have is: If we want to ignore CSRF for anonymous users, why do we still generate URLs with the token in there. When I understand \Drupal\Core\Access\CsrfTokenGenerator::get correctly, then we would simply generate a random token and then skip that in the access checker. I'm wondering whether we should / could suppress the generation of the token for anonymous users in \Drupal\Core\Access\RouteProcessorCsrf::renderPlaceholderCsrfToken

Patch looks reasonable and seems to have a side effect of making those links more cacheable for anonymous users

Per #4, this blocks Flag: #2475893: Support for Flagging by anonymous users.

#20++: The central question I have is: If we want to ignore CSRF for anonymous users, why do we still generate URLs with the token in there.

But most importantly: #11++: My point is that the CSRF protection should also work for anonymous users that have an active session.

I think https://www.drupal.org/node/2319205 may be a bit misleading. It says:

Generating tokens for anonymous users would require running php code and generating sessions for anonymous users. Most Drupal sites use a page cache built into Drupal and many sites use an HTML cache (such as Varnish) which prevents the generation of a per-user token inside of forms.

It is true that most sites have page cache enabled (well, pretty much every D8 site, since it's enabled by default now). And so, yes, if your forms do not require a session to work, then it's meaningless to have a CSRF token in them. But there definitely still are forms for anonymous users where you want sessions (and hence also CSRF tokens): some forms are user/session-specific, some are not. Those that are not don't need a CSRF token. But in case of an anonymous user interacting with a form that is:

1. a shopping cart, you want CSRF protection to prevent somebody adding products to my shopping cart on my behalf
2. a flagging/voting thing, you want CSRF protection to prevent somebody voting on my behalf (and also to help reduce endless voting by the same user)

So I'm not quite convinced yet.

We really need badges on drupal.org: David Rothstein, klausi and pwolanin are security team members (David is also a core committer) so I begin to think this is not horribly insecure.

That'd be very helpful indeed. Same for component maintainers.

@Wim this issue is only about route/link CSRF protection, it won't affect forms at all.

#29 But the same principles apply. Flagging/voting can be either via a link or via a form. You want CSRF protection either way.

Still, if we want we can add a session started check, that's easy. Do we want to?

Yes, I think that then this makes sense. Basically the session.exists cache context's logic: \Drupal\Core\Cache\Context\SessionExistsCacheContext::getContext(). This is also what BigPipe uses, see \big_pipe_page_attachments().

a shopping cart, you want CSRF protection to prevent somebody adding products to my shopping cart on my behalf -- well, what's "my" behalf if I am not authenticated? At one point I might add credit card information but there's no time between giving that and finalizing the shopping where another page could mess with my order. I do not think there's any site which remembers CC data for an anon user, that'd be insane.

There are certain things you could do like add a 'price-less' item to a cart that's part of a promotion to inflate numbers without the price changing.

Also some people might not notice an extra item or number of items in their cart before checking out - say if it's an order with a lot of items already. Thinking of online supermarket shopping where they almost put items in your cart themselves before they let you check out (three pages of "you're missing these promotions" " did you forget") or godaddy where you try to buy a domain and could end up with hosting, insurance, holiday in Crete etc. Given the upselling on sites like that, it'd be easy for an attacker to insert extra items without asking without someone reviewing their entire order again line by line.

So making session the distinction sounds good.

If session is the distinction, then shouldn't it be for forms too (which seems out of scope for this issue)?

I do think it's useful to have the same rules for CSRF protection on forms as on links, so that it's clear to people who have non-standard use cases (whether session-based or something else) whether Drupal is going to provide this security feature for them or whether it's their responsibility to handle the CSRF protection manually.

Hence the original suggestion to just bring links down to the level of forms here, and add more protection in a separate issue.

Eh that was a cross-post but maybe it proves the point since the patch is now a fair amount more complicated (and that's without even touching forms). The code looks good on a quick glance though.

So making session the distinction sounds good.

+1 to this.

Hence the original suggestion to just bring links down to the level of forms here

I have run into those kind of scenarios in which we needed the token for anon user links so I don't think this is good idea.

If session is the distinction, then shouldn't it be for forms too (which seems out of scope for this issue)?

Let's discuss this in follow up.

Overall patch looks good. I think we need a better title, change notice, perhaps update existing change notices and updated issue summary here other then that it is RTBC.

Thanks @chx for creating https://www.drupal.org/node/2759787.

Fails seem unrelated so retested.

So routes such as

outbound_processing_test.route.csrf:
  path: '/outbound_processing_test/route/csrf'
  requirements:
    _access: 'TRUE'
    _csrf_token: 'TRUE'

and

comment_test.report:
  path: '/comment/{comment}/report'
  defaults:
    _title: 'Report'
    _controller: '\Drupal\comment_test\Controller\CommentTestController::commentReport'
  requirements:
    _access: 'TRUE'
    _csrf_token: 'TRUE'

Yes these are test examples - but maybe contrib has real example... which before would not have worked for anon users now do? Maybe we should enforce that routes that use _crsf_token also have a _entity_access or _permission or maybe just don't have _access: 'TRUE'

This seems a risky behaviour change.

Going to set back to needs review for more discussion of #43. I think the intention of the issue is correct - csrf protection should not apply to anons and that is consistent with forms BUT the behaviour change during a major release cycle seems risky.

So, my understanding of prior Drupal versions was that CSRF tokens in forms were ignored by default for anonymous users. if you wanted them to be respected you had to do extra work yourself such as making sure the anonymous user had a session, that the form in question was not served from cache, and you adding back the validation.

This issue sounds like a bug fix to me - a bug fix may change incorrect behavior, so I am all in favor of fixing this.

The proposed fix sounds and looks reasonable, since it sounds like it would make it easier to support CSRF tokens for anonymous if desired.

I agree with David in #35 that the form and token behavior should be the same. I'm also not sure how readily this satisfies the need when a submission must have a CSRF token for anonymous - do you validate for the presence of a session or certain session data?

I think we need to address #43 and #46.

Since there is some risk associated with this change (plus internal changes to add a service etc.), let's target it for the minor development version at least.

Rerolling on 8.3.x. @socketwench got me interested in this issue.

Patch from #51 was successfully applied to Drupal 8.2.3 and fixed https://www.drupal.org/node/2835601. Thanks!

Patch no longer applies

Rerolled the patch.

Some more cleanup for previous patch & removed some coding standard issues also added a interdiff.

This issue is blocking the use of Dropzonejs for anonymous users in my project, which would be an important UX step (client-side resizing of images in a crowdsourced/mobile context). I can't do much but I'm willing to test a patch that applies on 8.4 if somebody can reroll it.

This patch applies cleanly to 8.4.x (and 8.5.x) so does not need a re-roll.

Sorry about that, I assumed the lasts tests failed for that reason.

This does need work though, because it's not yet passing tests.

#57 does not cleanly apply to 8.5.6

I re-rolled the patch from #57 based on the 8.6.x branch. This gets applied properly in 8.5.6.

The only change that I couldn't implement was in "core/modules/system/src/Tests/Common/UrlTest.php", since that file doesn't exist in 8.6.x. I'm not 100% sure on everything all of this code does, but I was careful in applying each code change and making sure there wasn't any php errors. Hopefully tests pass from this patch.

I verified that I am able to upload files via dropzonejs as an anonymous user. So this fixes the main issue for our use case.

ugh, it looks like tests are failing. :( Not sure how to fix. But the patch works.

The patch from #57 is trying to find /core/modules/system/src/Tests/Common/UrlTest.php, on last step, but the file doesn't exist for neither 8.5.6 nor 8.5.8.

Line number is 140 for patch from #57.

I've applied the patch #68 on 8.5.8. It went through but did not fix the issue.

I have applied #68 in my project.

Custom route configuration:

example.node.custom:
  path: '/node/{node}/example'
  defaults:
    _controller: '\Drupal\example\Controller\ExampleController::example'
    _title: 'Example'
  requirements:
    _entity_access: 'node.view'
    node: \d+
  options:
    parameters:
      node:
        type: entity:node

Tested with the following scenarios:

1. Clear the cookies
2. Log in as an authenticated user
3. Go to the sample page that contains a CSRF link generated from example.node.custom route
4. Click the link -> access allowed

5. ---

6. Log out
7. Go to the sample page that contains the CSRF link generated from example.node.custom route
8. Click the link -> access denied. This happens as \Drupal\Core\Access\CsrfAccessCheck::access() thinks the request still has the session

However, the scenario

1. Clear the cookies
2. Open the site as an anonymous user
3. Go to the sample page that contains the CSRF link generated from example.node.custom route
4. Click the link -> access allowed

works fine.

Question:

We have this problem:
https://www.drupal.org/project/drupal/issues/1803712#comment-13082004

Can you also provide these forms with a token if the issue on this page is solved?

I used this patch here on vote up_down module as it didnt work for both anon/auth users. Patch helps with anon but auth. users still cant use the widget for voting. Cross referencing it

https://www.drupal.org/project/vote_up_down/issues/3113901#comment-13467274

Patch applies to 8.8.4. It throws an error the first time I clear the caches, but no errors on the second cache clear. Patch allows anonymous users use the DropzoneJS uploader.

@capysara, what does the first error message include?

PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function Drupal\Core\Access\RouteProcessorCsrf::__construct(), 1 passed in /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php on line 269 and exactly 3 expected in /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php:49
Stack trace:
#0 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(269): Drupal\Core\Access\RouteProcessorCsrf->__construct(Object(Drupal\Core\Access\CsrfTokenGenerator))
#1 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'route_processor...')
#2 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(487): Drupal\Component\DependencyInjection\Container->get('route_processor...', 1)
#3 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php( in /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php on line 49

Fatal error: Uncaught ArgumentCountError: Too few arguments to function Drupal\Core\Access\RouteProcessorCsrf::__construct(), 1 passed in /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php on line 269 and exactly 3 expected in /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php:49
Stack trace:
#0 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(269): Drupal\Core\Access\RouteProcessorCsrf->__construct(Object(Drupal\Core\Access\CsrfTokenGenerator))
#1 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'route_processor...')
#2 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(487): Drupal\Component\DependencyInjection\Container->get('route_processor...', 1)
#3 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php( in /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php on line 49
[error] Drush command terminated abnormally due to an unrecoverable error.
Error: Uncaught ArgumentCountError: Too few arguments to function Drupal\Core\Access\RouteProcessorCsrf::__construct(), 1 passed in /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php on line 269 and exactly 3 expected in /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php:49
Stack trace:
#0 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(269): Drupal\Core\Access\RouteProcessorCsrf->__construct(Object(Drupal\Core\Access\CsrfTokenGenerator))
#1 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'route_processor...')
#2 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(487): Drupal\Component\DependencyInjection\Container->get('route_processor...', 1)
#3 /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php( in /var/www/drupalvm/drupal/docroot/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php, line 49

Patch did not apply. Here is a re-rolled patch. Please review.

A quick reroll of 81 for drupal 8.9

ps. this patch breaks some more tests than are fixed in the patch

Tried to fix failed tests in #87

Patch #90 fails with a serious regression, forbidden responses became allowed. This definitely needs work.

/**
* Constructs a CsrfAccessCheck object.
*
* @param \Drupal\Core\Access\CsrfTokenGenerator $csrf_token
* The CSRF token generator.
+ * @param \Drupal\Core\Session\SessionConfigurationInterface $session_configuration
+ * The session configuration.
*/
- public function __construct(CsrfTokenGenerator $csrf_token) {
+ public function __construct(CsrfTokenGenerator $csrf_token, SessionConfigurationInterface $session_configuration) {
$this->csrfToken = $csrf_token;

Should the new SessionConfigurationInterface dependency be nullable everywhere if we would like to introduce this fix in 9.x?

@amxr576 you're right, as the access result differ from entity and non-entity.

This patch applies to the latest version of 9.2.x and tries to handle such case, as returning "neutral" result for route using entity_access leads to security flaw.

I changed patch for 9.3.x version.

1. +++ b/core/lib/Drupal/Core/Access/CsrfAccessCheck.php
   @@ -54,7 +65,27 @@ public function access(Route $route, Request $request, RouteMatchInterface $rout
   +    if (!$this->sessionConfiguration || !$this->sessionConfiguration->hasSession($request)) {
   

   It seems this would mean that if the sessionConfiguration property is not set (e.g., you extended the class but did not update to include the new argument to the constructor) this code block applies even for authenticated users. Which does not appear to be the intent.

2. +++ b/core/lib/Drupal/Core/Access/CsrfAccessCheck.php
   @@ -23,14 +24,24 @@ class CsrfAccessCheck implements RoutingAccessInterface {
   +  public function __construct(CsrfTokenGenerator $csrf_token, ?SessionConfigurationInterface $session_configuration = NULL) {
        $this->csrfToken = $csrf_token;
   +    $this->sessionConfiguration = $session_configuration;
   

   Per above I think this needs to be retrieved from the \Drupal global DI container if it's not provided, and throw a deprecation notice.

3. +++ b/core/lib/Drupal/Core/Access/CsrfAccessCheck.php
   @@ -54,7 +65,27 @@ public function access(Route $route, Request $request, RouteMatchInterface $rout
   +      // We cannot return a neutral result, as this will mean "forbidden". This
   +      // may lead to unexpected behavior, when dealing with entity access, as
   +      // an "allowed" response will take over any "forbidden" one...
   +      // @see https://www.drupal.org/project/drupal/issues/2991698
   +      // @see https://www.drupal.org/project/drupal/issues/2861074
   +      if ($route->getRequirement('_entity_access') !== NULL) {
   +        $result = AccessResult::neutral('Anonymous users do not need CSRF checking');
   

   This is confusing to read, it says we can't return a neutral result, but then we do. I read through the linked issues and particularly https://www.drupal.org/project/drupal/issues/2991698#comment-14009628 explains this Drupal WTF, but it's still unclear here.

4. +++ b/core/lib/Drupal/Core/Access/CsrfAccessCheck.php
   @@ -54,7 +65,27 @@ public function access(Route $route, Request $request, RouteMatchInterface $rout
   +      // Regarding non-entity route access, this is not an issue as any "neutral"
   +      // or "forbidden" result with take precedence.
   

   This needs grammar cleanup.

Note to self, the patch that seems to be most recently seen by core maintainers is #51. The patch reviewed above includes changes in #95 relating to entity routes; I've read through the comments and I'm not entirely clear why that needs to be in here at all, actually.

@xjm last chimed in on this at #50. I came here from #3055260: [PP-1] Disable CSRF token check for non-CSRF vulnerable authentication providers which is a similar problem space (need to disable CSRF checks) but is a little (a lot?) simpler b/c it only hinges on the authentication method used, so by definition only speaks to authenticated users. That will be easier than here, where there's question around when and how to apply CSRF protection for anons, and URL generation.

Any update for d9.3 ?

I've updated patch #51 to the code standard required by both version d9.3 and above.

Fixing test issues.

Fixing PHPCS issues.

Patch #105 works on drupal/core (9.4.2)

Rerunning the tests for 9.5.x

Any testing steps would be great!

I have a related issue about dropzonejs/upload 403 error for the anonymous users in Drupal core 9.4.7 after the site was upgraded from Core 9.3.6 to 9.4.7.

It worked well for the anonymous users to upload Media files in Drupal Core 9.3.6. Now the "en/dropzonejs/upload?token=WcMvqfFb5tLuF1kfaxBZhTspoW9enzzs4bf02xp9gc0. Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: 'csrf_token' URL query argument is invalid" error occurs. I applied the patch (2730351-105.patch) in the site. As a result, the error is gone. But the anonymous user still can't upload the files in the Core 9.4.7.

Great work. Thank you @erick.major for providing the patch #105!

The patch allows the anonymous user to upload the files on Drupal Core 9.4.7. For some reason, the file is not converted as a Media type and its status indicates "Temporary" even though the Administer media permission is granted to anonymous user role.

Hi @erick.major, do you have any suggestions on why the media item is not generated after the file was uploaded by the anonymous user in Drupal Core 9.4.7. And the uploaded file status shows "Temporary" in file_managed table and the file list (/en/admin/content/files). The anonymous user role has the Administer media permission. Thank you.

Rerolled the patch against 10.1x.

Re-roll against core 9.5.0

Fixed CCF for #116.
Please review.

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.

No longer applies to Drupal 9.5.9.

I rerolled the patch for Drupal 9.5.9
I have to learn to how to do a proper interdiff.
The changes below are just text changes in comments

patching file 'core/core.services.yml'
patching file 'core/lib/Drupal/Core/Access/CsrfAccessCheck.php'
patching file 'core/lib/Drupal/Core/Access/RouteProcessorCsrf.php'
patching file 'core/modules/menu_link_content/tests/src/Kernel/MenuLinkContentCacheabilityBubblingTest.php'
1 out of 4 hunks failed--saving rejects to 'core/modules/menu_link_content/tests/src/Kernel/MenuLinkContentCacheabilityBubblingTest.php.rej'
patching file 'core/modules/system/tests/src/Kernel/Common/UrlTest.php'
1 out of 7 hunks failed--saving rejects to 'core/modules/system/tests/src/Kernel/Common/UrlTest.php.rej'
patching file 'core/tests/Drupal/Tests/Core/Access/CsrfAccessCheckTest.php'
patching file 'core/tests/Drupal/Tests/Core/Access/RouteProcessorCsrfTest.php'

more core/modules/menu_link_content/tests/src/Kernel/MenuLinkContentCacheabilityBubblingTest.php.rej
@@ -15,6 +15,8 @@
use Symfony\Component\Routing\Route;

/**
+ * The menu link content cache bubbling kernel tests.
+ *
* Ensures that rendered menu links bubble the necessary bubbleable metadata
* for outbound path/route processing.
*

more core/modules/system/tests/src/Kernel/Common/UrlTest.php.rej
@@ -12,6 +12,8 @@
use Drupal\KernelTests\KernelTestBase;

/**
+ * Url kernel tests.
+ *
* Confirm that \Drupal\Core\Url,
* \Drupal\Component\Utility\UrlHelper::filterQueryParameters(),
* \Drupal\Component\Utility\UrlHelper::buildQuery(), and

Please review.

Test failure.

Sorry, I can see the all tests passed. Which tests failed?

Left some feedback on the MR.

Rerolled patch for D10.1.x

Can confirm #128 applies cleanly and works on Drupal 10.1.6

This needs an MR against 11.x at this point.

It's possible to remove/disable the CSRF check by using a directive set to the modulename.routing.yml file

see how this patch for dropzonejs is doing it:
#3197207-02: Anonymous users cannot upload caused by invalid csrf-token

This patch is for 10.3.x version

How does this committed issue #144538: User logout is vulnerable to CSRF and the change record https://www.drupal.org/node/2822514 affect this issue, #2730351: CSRF check always fails for users without a session?

Leaving as needs work.

#132 failed to apply for me on 10.3.0. Re-rolled against branch 10.3.x

A new patch for Drupal Core 10.3.7 was generated from 2730351-D10.3.x-134 patch

The patch #135 stopped working after updating to 10.4.2

confirm #136 - patch #135 works until 10.4.1, stopped working with 10.4.2

couldn't apply the MR diff either, so I'm stuck at 10.4.1 for the given project :(

A new patch for Drupal Core 10.4.2 was generated from drupal-core-10.3.7-2730351-135.patch

@sabrina.liman Please do not change the version or the category. Core development is currently on 11.x.

Error occurred with #139

PHP Deprecated: Optional parameter $requestStack declared before required parameter $session_configuration is implicitly treated as a required parameter in /var/www/html/docroot/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php on line 28

Deprecated: Optional parameter $requestStack declared before required parameter $session_configuration is implicitly treated as a required parameter in /var/www/html/docroot/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php on line 28
PHP Fatal error: Uncaught TypeError: Drupal\Core\Access\RouteProcessorCsrf::__construct(): Argument #2 ($requestStack) must be of type ?Symf
ony\Component\HttpFoundation\RequestStack, Drupal\Core\Session\SessionConfiguration given, called in /var/www/html/docroot/core/lib/Drupal/Co
mponent/DependencyInjection/Container.php on line 261 and defined in /var/www/html/docroot/core/lib/Drupal/Core/Access/RouteProcessorCsrf.php:28

@sabrina.liman , patches are no longer preferred, please use existing MR to contribute or create a different MR if you have an alternative solution than the existing one.

Patch #141 also doesn't work since it has a critical issue: Uncaught PHP Exception Error: "Call to a member function hasSession() on null" at /core/lib/Drupal/Core/Access/RouteProcessorCsrf.php line 44

I understand MR is better, but I didn't have enough time to do that.

In the meantime, if you still need this patch to be applied on a drupal 11.2.3 instance, here is a bump.