ACL: plugins functionality (often triggered by request-scope) need access to their configuration topics in the "System" workspace

[Malte]

.. the plugin, e.g. the dm4-sign-up module, has a notification-feature which sends out a notification on each account creation. The recipient is a (end-user) configurable "Administrators E-Mail Address"-topic (As of 4.6 residing in the "System"-workspace. Since the notification-send implementation is triggered from within a request-scope the topic cannot access its own configuration topic (because it just has the access rights for the resp. user making the request).

The underlying question here, from my perspective, is:
Is sending a notification e-mail (on each sign-up) considered to be A) an action by the entity registering herself in our system or by B) the "System".

In this case, i think B), sending a notification to administrators is an action of the "System" and not the "Anonymous user."

This applies basically to all "system configuration topics" editable by "admin" at runtime, such as "API Endpoint", "SMTP Host" or a "Default Language"-setting.

What do you think?

Workaround:
One workaround would be to load all resp. "configuration topics" for a module during "init" and require a "bundle refresh" to reload the plugins settings.

Related case (#813):

• A plugin wanting to "write" an E-Mail Address value to the "User Account" topic during account registration.

[jri]

It is not up to the plugin developer to decide what action runs under the "System" authority (#764). The "System" authority represents a natural border between the system and its users:
Code which is triggered by a user (that is through a HTTP request) runs under the user's authority.
Code which is triggered by the system itself runs under the "System" authority.
Blurring this border would mean to create a security hole.

A case for the "System" authority: suppose the next version of a plugin changes its data model and must convert all existing data, data that is created by different users. The data conversion must be performed by the "System" authority, and in DM this is the case as it is performed when the plugin is deployed (and its migrations are run). Deploying a plugin is not initiated by a user but by the system itself.

Workaround:
One workaround would be to load all resp. "configuration topics" for a module during "init" and require a "bundle refresh" to reload the plugins settings.

This would work as a plugin's "init" hook is triggered by the system itself and thus runs under "System" authority.

Related case (#813):
A plugin wanting to "write" an E-Mail Address value to the "User Account" topic during account registration.

A User Account is owned by the respective user. DM assigns a User Account to the user's private workspace. Thus only the user itself or the system can edit an User Account. This is the current design (#592) and looks right to me.

From my point of view (as the access control architect) you're basically saying that anonymous must be able to edit any user account (provided the sign-up plugin's requests are sent as anonymous, which they are). This looks not right to me.

A solution would be what I've sketched out in ticket:813#comment:2

I think we should resort to an email based workflow after all. The Sign-up action just sends an email. This email could be answered either 1) by an admin who creates the account manually, or 2) automatically by the system (which runs under the System authority anyway, #764, and have all privileges). We could start with the manual way as it requires much less development work in advance.

Approach 2) would mean that the sign-up plugin would interpret incoming emails, basically by registering a listener at the SMTP server. The listener is invoked by the SMTP server (when an email arrives) and thus runs under "System" authority.

In order to launch our myDM service soon (Sep 3 would be fine :-) I would go for approach 1), the manual approach. This way we would get a picture about user acceptance soon. In the meantime we could work on approach 2) resp. discussing this issue further.

[jri]

To my knowledge this is solved meanwhile. See #816.