Issue #3502654: ECA model
Closes #3502654
Merge request reports
Activity
63 parameter_name: node 64 successors: 65 - 66 id: Activity_not_found_exception 67 condition: Flow_unpublished 68 Activity_and: 69 plugin: eca_void_and_condition 70 label: AND 71 configuration: { } 72 successors: 73 - 74 id: Activity_switch_user_1 75 condition: Flow_user_not_perm_view_unpublished 76 Activity_switch_user_1: 77 plugin: eca_switch_account 78 label: 'Switch to user 1' 
It is necessary because the model is processed in the context of the anonymous user, and they don't have permission to load the node.
I know, the special permissions of user 1 can be turned off. That's why we have implemented a new feature in ECA to configure a "Service user", see https://www.drupal.org/project/eca/issues/3502614 - that just happened yesterday :-)
For Drupal CMS we should leverage that service user by creating an account during installation with sufficient permissions that won't be used for authentication, but that would be used by ECA models to escalate privileges.
I don't really understand 'they don't have permission to load the node'.
Entity loading doesn't depend on permissions, the node has already been loaded for this request is this permission to use the ECA action? I will fully admit that learning ECA by reviewing MRs is not a good necessarily a good way, but I hope at least some of the questions are useful. But having to switch to user 1 to load a node seems like more could go wrong than just allowing anonymous users to load nodes.
Also the loaded node is available in the route parameters so theoretically would not need to be loaded again.
-
Sorry, I wasn't explaining that correctly. It's not about loading the node, you're right that this is already loaded by the route. It's about sticking that node into a token, which is prevented here. Because as soon as the node is in a token, data from the node can be exposed by subsequent actions, and that would expose data to un-permitted users.
The access control concept from ECA has been from day 1, that each action plugin can implement their access control, and we tried to implement that consistently in all of ECA's plugins. The ECA processor is supposed to execute within the context of the current user. And yes, that's irritating sometimes, but we're strong believers in security first. That's why the user who has the permission to build ECA models, i.e. a user with pretty high privileges because ECA modelling is like programming, can explicitly switch user context in a model when it's necessary to perform a task. But that's a deliberate decision, and the scope of that account switch is very limited: ECA automatically switches back to the current user as soon as the subsequent actions to that (and only that) user switch have been completed. So, everything else in ECA processing (and also for the rest of the current PHP process), there is no extra danger of granting more privileges unintentionally.
added 6 commits
-
ba4df514...a0aaba3b - 4 commits from branch
project:1.x - e31d9965 - Merge branch '1.x' into 3502654-eca_unpublished_404
- 76ee7fba - Issue #3502654: ECA model
-
ba4df514...a0aaba3b - 4 commits from branch
