Wrong user logout CSRF token

I tracked it down: the problem is the wrong token, is not a token, it's a placeholder, which ought to be replaced by the renderer.

See the logic of RouteProcessorCsrf:

      // Adding this to the parameters means it will get merged into the query
      // string when the route is compiled.
      if (!$bubbleable_metadata) {
        $parameters['token'] = $this->csrfToken->get($path);
      }
      else {
        // Generate a placeholder and a render array to replace it.
        $placeholder = Crypt::hashBase64($path);
        $placeholder_render_array = [
          '#lazy_builder' => ['route_processor_csrf:renderPlaceholderCsrfToken', [$path]],
        ];

        // Instead of setting an actual CSRF token as the query string, we set
        // the placeholder, which will be replaced at the very last moment. This
        // ensures links with CSRF tokens don't break cacheability.
        $parameters['token'] = $placeholder;
        $bubbleable_metadata->addAttachments(['placeholders' => [$placeholder => $placeholder_render_array]]);
      }

\Drupal\Core\Render\MetadataBubblingUrlGenerator::generateFromRoute() seems to activate this logic always, even when the Url is generated with $url->toString(FALSE).

to reproduce, run this with drush php

> \Drupal\Core\Url::fromUri('internal:/user/logout')->toString();
= "/user/logout?token=fzL0Ox4jS6qafdt6gzGzjWGb_hsR6kJ8L8E0D4hC5Mo"

compare the token with the right token, it's wrong, it's the placeholder value. So seems this is triggered by a core bug.

However, additionally rest_menu_items has a bug since it calls > \Drupal\Core\Url::fromUri('internal:/user/logout')->toString(TRUE); but throws the resulting bubbleablemetadata away. By throwing it away, the placeholders won't be replaced.

Generally, I think the module should re-use the pre-existing $url object provided by the menu API and not re-create it with the uri. When done so, we'd not trigger bugs like this one.

so, re-using the pre-exiting url object does not solve it either. Anyway, Drupal core generates the token with a placeholder, but since we are not rendering obviously placeholders are not replaced. :-( I wonder how this is solved for the drupal core menu linkset api.

tested it. it does not - it faces the same problem. Let's open a core issue!

--> #3485174: Menu APIs provide invalid CSRF tokens

I can confirm this is fixed now. With the fix in core, this works, so let's mark this as fixed also!