A REST resource's "auth" configuration MUST be non-empty, which prevents configuring it for anon access only

Even if not, don't we even in this case fallback to the default authentication, which is cookie by default?

Correct. Note that for that problem/aspect I have #2817745: Add test coverage to prove that REST resource's "auth" configuration is also not allowing global authentication providers like "cookie" when not listed.

So that would be a totally valid configuration?

If by that you mean that supported_auth: [] is totally valid, then yes. If not, can you clarify?

Configuring an auth provider for anonymous is an explicit requirement that could be handled via a sensible default.

What are you suggesting exactly?

Right now, the problem is that Drupal will yell if your anonymous resource is insufficiently configured. At least it "yells".

In what way does it "yell"? Logging to watchdog is very very easily missed.

Removing this, and setting up authenticated resources will have an unmet, implicit dependency that will be confusing to troubleshoot. I don't think this should go forward as-is without a planned follow-up to make authenticated access to REST resources less touchy by default.

I would argue it is confusing today.

This issue is just meant to make things logical for "authless" resources. For making it more clear for authenticated resources, there is #2817745: Add test coverage to prove that REST resource's "auth" configuration is also not allowing global authentication providers like "cookie" when not listed.

which I slightly conflated with how confusing this is to set up with the REST UI module enforcing the current expectations.

Yep, that's exactly part of the problem. REST UI exposes the very same problems in the UI: the same problems that you have if you manually set up this YAML file.

That sounds sensible!

+++ b/core/modules/rest/src/Routing/ResourceRoutes.php
@@ -94,7 +94,10 @@ protected function getRoutesForResourceConfig(RestResourceConfigInterface $rest_
+        if ($authentication_providers !== [] && empty($authentication_providers)) {

Wouldn't empty($a) && $a !== NULL be clearer?

So, I worked on #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method, and that does also have explicit anonymous test coverage. Why does that work?

Two reasons:

1. Because "anonymous" is not an authentication provider you even can list, so it's always allowed. It just means you need sufficient permissions. (This issue would not change that.)
2. Because it has similar incorrect logic that \Drupal\rest\Tests\RESTTestBase::enableService() has. It's slightly different though: \Drupal\rest\Tests\RESTTestBase::enableService sets it to ['cookie'], if you don't specify allowed auth. \Drupal\Tests\rest\Functional\EntityResource\EntityResourceTestBase::provisionEntityResource() just sets [FALSE] if you don't specify allowed auth. And yes, everything accepts this: the RestResourceConfig entity (because it doesn't do validation) and the routing system (because it maps this to the empty string). It only works thanks to the entire system being incredibly non-strict.

By fixing EntityResourceTestBase::provisionEntityResource(), we automatically gain test coverage.

Thinking about this more, and playing with this, I actually had interpreted ~ (i.e. NULL) as the way to specify the intention to only allow anon access. Because ~ is currently not yet allowed by the REST Resource config schema.

But thinking about this again, I think it makes sense to just use the empty array for that. Because you can never choose to not allow anonymous access. Anonymous access to a resource is always allowed. That's how the routing system works.

This is the direction I went with first: ~ (NULL) means anonymous only.

And this is if I follow what @dawehner initially proposed. Note that the value can never be NULL. So this:

+++ b/core/modules/rest/src/Routing/ResourceRoutes.php
@@ -94,7 +94,10 @@ protected function getRoutesForResourceConfig(RestResourceConfigInterface $rest_
+        // We want to allow people to specify no authentication providers by
+        // using @code [] @endcode explicitly.
+        if ($authentication_providers !== [] && empty($authentication_providers)) {

does not make sense. Unless we of course again update the config schema to allow NULL, and then NULL becomes the way to truly specify "no authentication providers", but then that also doesn't actually make sense, because A) we don't allow that in the code anyway, so why allow it in the config schema?, B) not allowing any authentication providers would still allow anonymous access, and that's exactly what the empty array already signifies.

In other words: that logged error ceases to make sense, and that's all!

Of course, if some of you think oh, but isn't it dangerous/misleading to allow anonymous access to a REST resource?, then I don't disagree!

But the thing is that we've always allowed anonymous access to any REST resource!

I personally think what would be clearest is if we would break BC (it'd be a soft BC break, because it's unlikely many sites are relying on anonymous access to REST resources), and do this:

1. allow 'anon' to be specified in the REST Resource config entity's authentication section
2. this would not be an actual authentication provider, but would be an explicit signal to allow anonymous access
3. in \Drupal\rest\Routing\ResourceRoutes::getRoutesForResourceConfig(), set _user_is_logged_in: 'TRUE' unless this 'anon' authentication provider is explicitly mentioned
4. the end result would be that anonymous access is forbidden unless a REST resource's configuration explicitly allowed it — hence removing the requirement that if you don't want anonymous users to access REST resources, that they have some permission (which btw is the case by default, because \Drupal\rest\Plugin\ResourceBase::permissions() generates a permission for every method for every resource, unless you opt out from that)

By not having cookie based auth, even for anonymous users, then we lose the anonymous session cookie, which I believe plays some role in creating CRSF tokens.

Glad you raised it, I've gotten confused by that myself too :)

CSRF tokens are only necessary for cookie auth. Basic auth, OAuth 2 etc are not vulnerable to CSRFs (because you can embed a URL that would be triggered by an unwitting user, but it would never include Basic Auth or OAuth 2 request headers — the same is not true for cookies).

Furthermore, allowing anonymous implies allowing anybody to access a resource, so CSRF is irrelevant: anybody can do these things. (So you'd probably only allow GET for anonymous users.)

The contrib module REST UI's #2332797: Add option to allow access to resource (or a particular method on a resource) without authentication (i.e. as anon) problem cannot be fixed without this being fixed.

Actually, this means that \Drupal\user\Plugin\rest\resource\UserRegistrationResource which was added in #2291055: REST resources for anonymous users: register cannot be used at all in practice.

If you set this up and comply with REST UI's demand to specify an authentication method and choose e.g. basic_auth, registration fails because:

{
  "message": "Only anonymous users can register a user."
}

And if you manually modify the user_resource REST Resource Config entity, so that it has:

authentication: []

(i.e. no authentication mechanisms) then the corresponding REST route is never created.

The only way to have it work is to associate the cookie authentication mechanism… and then not send a session cookie. Because \Drupal\user\Authentication\Provider\Cookie is a global authentication provider, this is accepted. This is a huge WTF.

EDIT: and yes, we have test coverage: \Drupal\user\Tests\RestRegisterUserTest. But it only works due to chance: it doesn't explicitly enable the cookie authentication provider, that just happens to be the default. in RESTTestBase::enableService(). IOW: this test coverage only works by accident!

Improved issue summary: explained how the current REST test coverage for the anonymous use (NodeJsonAnonTest, CommentHalJsonAnonTest, and many dozens others) manage to work around this.

Revamped IS.

There are now two proposed resolutions in the IS. Solution 1 == patch in #18. Solution 2 does not yet have a patch, but was proposed in #19.

This is blocked on a decision which solution is preferred. Hopefully we can get a framework manager to express a preference for either one, otherwise we may be wasting a lot of effort.

I somehow never saw #31! :(

This statement is confusing. How is this dangerous, its really common to render stuff for the anonymous user.

Sorry, I meant "allowing anon access by default".

I don't see a problem, it could be literal a anon provider, which returns an anonymous user as result of the authentication.

+1!

I like where this patch is going, @dawehner++

Rebased, let's see how many failures it has today. Even though the routing system now has fewer bugs, the number of failures is likely much higher, simply because there's far better REST test coverage now.

HAH! Nice! 👌

All basic auth tests are failing like this:

Failed asserting that 403 is identical to 401.

Now they are 403s saying that the used authentication method is not allowed. But it used to be a 401, thanks to \Drupal\Core\EventSubscriber\AuthenticationSubscriber::onExceptionSendChallenge() converting the 403 exception (AccessDeniedHttpException) into a 401.

Now it's impossible in practice to ever reach that point. Because in \Drupal\Core\EventSubscriber\AuthenticationSubscriber::onKernelRequestFilterProvider(), $this->authenticationProvider->applies($request) returns true for Anon (which makes sense), which results in that 403 exception.
But then because that exception is thrown, we reach \Drupal\Core\EventSubscriber\AuthenticationSubscriber::onExceptionSendChallenge(), we check !$this->authenticationProvider->applies($request) (the inverse!), which can then of course never be true *also*.

The problem is that onExceptionSendChallenge() never took into account that some authentication provider would always apply. It assumed it would only ever be called when access was denied because the user wasn't logged in. This is wrong.

What we should do, is update \Drupal\Core\EventSubscriber\AuthenticationSubscriber::onExceptionSendChallenge() to iterate over only the authentication providers that allowed on the requested route, instead of iterating over all authentication providers.

I don't yet see how to achieve that without making BC breaks. For now, here's a work-around that allows us to focus on fixing the other problems first. (I spent an hour trying.)

Somebody asked again about this WTF in #2949327-6: Help with REST authentication.3.