Problem/Motivation

It is frustrating to define API-first routes if you do not care which authentication method is used since it can only be done programmatically. This is because the route developer can't know which methods the site builder has enabled (e.g. basic_auth) in advance, but every authentication method must be explicitly specified.

See an example in core.
See an example in contrib.

Proposed resolution

Allow routes to be defined with _auth: 'TRUE' to permit any available authentication method.

Alternative
If _auth is not defined, allow all methods instead of the default method. This would make it easier to define routes, but may break existing expectations.

API changes

Additional allowed value in a route definitions.

Data model changes

None.

Release notes snippet

Routes can now be defined to permit all enabled authentication methods without writing custom code by specifying _auth: 'TRUE' in their route definitions.

Comments

gabesullice created an issue. See original summary.

gabesullice’s picture

gabesullice
Primary language English
commented
Issue summary: View changes

Clarified the IS a bit.

gabesullice’s picture

gabesullice
Primary language English
commented

While trying enable the default REST resource for nodes, I was frustrated because I could not simply visit localhost/node/1?_format=hal_json after enabling HAL + REST. It took me a couple minutes to realize that I was getting a 403 Forbidden because the system didn't like my cookie (I was logged in as uid 1). If I did not have lots of experience with these things, I expect this would have taken me a lot longer. I suspect the reason that REST configuration only enables basic_auth out of the box is really a consequence of this issue.

It seems like, in general, authentication methods should be a sitewide configuration, not a per-route configuration. This makes me think that the alternative solution is preferable:

Alternative
If _auth is not defined, allow all methods instead of the default method. This would make it easier to define routes, but may break existing expectations.

We could add a BC flag to keep the old behavior for existing sites, but the above seems like a nice DX improvement to make.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#3039568: Add a read-only mode to JSON:API

It seems like, in general, authentication methods should be a sitewide configuration, not a per-route configuration. This makes me think that the alternative solution is preferable:

I think the original thinking behind making this per-route for "REST resources" is to have fine-grained control over security implications.

It reminds me of what we were required to do in #3039568: Add a read-only mode to JSON:API for security considerations.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

aubjr_drupal’s picture

aubjr_drupal commented

Thanks, @gabesullice for https://www.drupal.org/project/drupal/issues/3200620#comment-14040318.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.