Any specific reason not to use direct calls like $store->getDefaultCurrencyCode() or $currency->getSymbol()? Maybe these weren't available back then? They sure are now...

Instead of controllers, you might want to use the REST API and create @RestResource plugins. CSRF authentication then comes from the cookies auth provider.

Unfortunately, this is part of an ongoing, older problem. For instance, Drupal forces CSRF checks on non-GET resources automatically, even is the cookie provider is not used for a resource. This is part of the same problem, nothing actually enforces that only the providers you specify are actually used. (And, what's worse, it doesn't look like removing the _csrf_request_header_token requirement on the route does anything about it.)

I think I'll have to go with that (although this still makes it two places where I need to maintain the URL). Another idea was to use a dummy query variable just in these calls but that feels even less elegant. :-)

That's what one of my provider's ˙applies()` does. But the second one would need to provide anonymous access (no CSRF token or cookie or anything similar required at all). I have nothing to check for in that applies() and returning TRUE clearly breaks the whole site. That's why it's a trouble I can't force this provider to only apply to a single, specific route.

But then, what's the point of checking what auth is supported for a given resource, if all will be called, anyway?

Well, the comments in AuthenticationProviderFilterInterface do suggest a probable cause, so this might be the sad truth after all...

I'd also override getCacheMaxAge() to return zero to avoid caching it.

In this particular case, it works OK with the return, this is already the last line of the build() function. Thanks.