Proposal (breaking): Change the way scripted document updates are handled
See original GitHub issueWhile I was working on something, I realized that for every doc.insert
or doc.save
the document’s last update is attributed to the session user and also permissions are validated. When done programmatically either via a script or controller (example: changing status of an Issue to “Open” when a new Communication is made), this is wrong because the session user does not control the internal update. So I am proposing 2 changes:
- Don’t attribute the change to the session user, attribute it to a system user, maybe create a new user called “System” that indicates that the document was updated programmatically, or just use “Administrator” (but that is also wrong)
- Don’t check permissions internally. Default
ignore_permissions
to True except for REST API updates.
Planning to send a fix soon to develop
in time for v14. I understand there maybe certain security concerns on bypassing permissions check, but if the updater is “System”, then those checks are mostly meaningless. There are upteen cases where we have to add ignore_permissions=True
on the ORM update - which we can now avoid.
If there are any other major concerns, please share!
Issue Analytics
- State:
- Created 2 years ago
- Reactions:5
- Comments:5 (2 by maintainers)
Top GitHub Comments
Just noticed this behaviour today, in one of our sites. Your proposal would make things clearer. Minor issue, but it seems unfair to 'blame" users for system behaviour.
Would there a global setting per app that ignores or allows by default?
So that should there be a security sensitive organization that wants to force check for all custom apps, then it can be enforced.