Ticket #829 (closed Enhancement: wontfix)
Access Control: programatic switching to "System" role
| Reported by: | jri | Owned by: | jri |
|---|---|---|---|
| Priority: | Major | Milestone: | Release 4.7 |
| Component: | DeepaMehta Standard Distribution | Version: | 4.6.1 |
| Keywords: | Cc: | dgf, Malte, JuergeN | |
| Complexity: | 5 | Area: | |
| Module: | deepamehta-accesscontrol |
Description
Plugins must be able to deliberately execute certain code under the "System" authority. This is required by system-near plugins like DM4 Sign-up.
The measures already taken to undermine the access control system must be reverted then:
- AC Service's createUserAccount() and getUsernameTopic() methods must not be invokable via unauthorized request (#811).
- The Core's public AccessControl? support object must be dropped.
Change History
comment:2 Changed 9 years ago by jri
- Status changed from accepted to closed
- Resolution set to wontfix
Sorry, change of plan. For the moment I decided not to provide a generic "run as system" mechanism. I want avoid proliferation of privileged code. Developers might be seduced to resort to privileged code too early and thus possibly undermining the access control mechanism without a need.
Instead I go for a fixed set of privileged methods as specified in the Core's AccessControl interface. This set might be expanded in communication with the Core developer. My feeling is that the AccessControl interface will finally converge to a fixed state.
