Toggle access control per model and per action

Created on 22 May 2024, 6 months ago
Updated 12 June 2024, 5 months ago

Problem/Motivation

By default, ECA processes models in the context of the current user. Each action can perform an access control and refuse to process that action, if the current user doesn't have the required permission.

If processing needs to be enforced, even if the current user doesn't have all the permissions, ECA provides 2 options:

  • Use the "Switch current user" action, to temporarily change the context to another user with the appropriate permissions.
  • Globally change the ECA settings to always process models in the context of a specific configured user account.

The first option is sometimes perceived as too cumbersome, and users don't like it if they have to add that extra action almost everywhere.

The second option has the downside, that it is global and models that will be shared with other Drupal sites may behave differently depending upon that setting.

Proposed resolution

Let's add 2 more options in addition to what we already have:

  • A property for each model to turn off access checks for all action with just for that model.
  • A property for each action to turn off access check just for that action.
Feature request
Status

Active

Version

2.1

Component

Code

Created by

🇩🇪Germany jurgenhaas Gottmadingen

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @jurgenhaas
  • 🇩🇪Germany mxh Offenburg

    How do you want to turn off access checks? It's worth noting that current implementations of the access method of most ECA-related action plugins are not only performing access checks, but also validations, as can be seen in the commits of 📌 Enhance (or add) access control in plugins where required config fields support tokens Active . If we'd want to be able to optionally turn off access checks, I currently see two options:

    1. Refactor all access method implementations, so that the access methods exclusively contain access checks (probably mostly permission or role-based checks) and put any other logic such as validation and appliance checks into separate method(s)
    2. Skip all permission/role-bases access checks within the access method implementations e.g. with wrapped if statements that check whether access checks are enabled/disabled.
  • 🇩🇪Germany jurgenhaas Gottmadingen

    This is a great observation, thanks @mxh

    What we currently have, are 2 components in access checks:

    • Permission checks
    • Validation checks

    Each action can have none, one, or all those components in the access method. Also, worth noting that the execute method sometimes also does the validation again.

    So, what we optionally want to turn off, is just the permission check. And that does require a refactor of action plugins in any case. In other words, if access check is turned off, we still wish to refuse execution if the configuration is not valid.

    An approach without re-factoring could be to switch to user 1 or an admin user right before calling the access method, and switching back right afterwards. But the privileges of user 1 may be turned off (new feature in core) or no admin role may exist. Maybe the new permission API could be helpful instead?

  • 🇩🇪Germany jurgenhaas Gottmadingen
Production build 0.71.5 2024