Problem/Motivation

Uploading files via rest is not allowed when a user / role DOES have permission for the bundle. The error thrown is below;

Path: /file/upload/node/{bundle}/{field}?_format=hal_json. Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: in Drupal\file\Plugin\rest\resource\FileUploadResource->validateAndLoadFieldDefinition() (line 443 of /var/www/d9/core/modules/file/src/Plugin/rest/resource/FileUploadResource.php).

A bare-bone Drupal installation does not have "field permissions" unless installing "Field Permissions" module. The way I see it, it is impossible to upload a file for other roles apart from an administrator.

If a role has create/edit permission on the bundle, the field should inherit the bundle permissions.

```

$entity_access_control_handler = $this->entityTypeManager->getAccessControlHandler($entity_type_id);
    $bundle = $this->entityTypeManager->getDefinition($entity_type_id)->hasKey('bundle') ? $bundle : NULL;
    $access_result = $entity_access_control_handler->createAccess($bundle, NULL, [], TRUE)
      ->andIf($entity_access_control_handler->fieldAccess('edit', $field_definition, NULL, NULL, TRUE));
    if (!$access_result->isAllowed()) {
      throw new AccessDeniedHttpException($access_result->getReason());
}

```

Steps to reproduce

Make a post request to "/file/upload/node/{bundle}/{field}?_format=hal_json" as any role apart from administrator.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

sadikyalcin created an issue. See original summary.

sadikyalcin’s picture

sadikyalcin commented
Issue summary: View changes
sadikyalcin’s picture

sadikyalcin commented
Issue summary: View changes

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

Drupal 9.1.10 (June 4, 2021) and Drupal 9.2.10 (November 24, 2021) were the last bugfix releases of those minor version series. Drupal 9 bug reports should be targeted for the 9.3.x-dev branch from now on, and new development or disruptive changes should 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.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Issue tags: +Bug Smash Initiative

This came up as a daily BSI

Don't have time to fully setup but would be good to confirm first if still an issue in D11.

mohit_aghera’s picture

mohit_aghera commented
Status: Active » Postponed (maintainer needs more info)

I tried to reproduce the issue based on the description.
It seems that current implementation is done on purpose to prevent accidental file upload issue.
It was implemented in #1927648: Allow creation of file entities from binary data via REST requests.

The comment #326 from @berdir summarises the purpose of the access mechanism.

The advantage of uploading for a specific field is that we don't have to worry about temporary:// IMHO. Because we can just create it as a normal public:// (or whatever is configured on that field) temporary (the status, not the location) file, just like when you upload in the UI. It would also fix the permission problem, because we can easily check edit access to that specific field for that node type. That means you can really only upload files if there's at least one file/image field on an entity type/bundle that you are allowed to edit.

Currently field access is returning the correct results.

$access_result = $entity_access_control_handler->createAccess($bundle, NULL, [], TRUE)
      ->andIf($entity_access_control_handler->fieldAccess('edit', $field_definition, NULL, NULL, TRUE));

If we see the fieldAccess() method, https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co..., it eventually calls checkFieldAccess https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co... which returns true since operation is edit.

Later in the `checkFieldAccess()` we are checking field "entity_field_access" hooks.

Please reopen the issue if you feel it is causing further regression.

smustgrave’s picture

smustgrave commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

Since there's been no follow up going to close out as working as designed. Can always be re-opened if needed.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.