1. What you describe is certainly possible with Everlive. What we need to do is find out the best way to implement the security in your app so it is simple yet easily manageable.
2. All of the predefined security patterns allow some CRUD operation to anonymous users. To get the behavior you need you can use role-based security. It allows you to specify what CRUD operation is available for each role. If you deny all operations for all roles, CRUD actions will only be possible with masterkey access. Additionally, if you add new roles, they are automatically set to have no permissions, so you are safe on that front as well. You can read more about role-based security here.
3. You will find a proposition on the whole security system below.
We assume from the sample tables in your post that each group has a single administrator and each message is created for a single user.
If you want to register multiple admins to a group and to send messages to multiple users (always within this group) there is a different approach, which is also described below.
4. To prevent this error from the cloud code, you should use masterkey access from there. By default, when you use "Everlive.Sdk.$" requests are made using the authentication of the current request(anonymous in your case). You can easily make requests with masterkey if you use "Everlive.Sdk.withMasterKey()" instead of "Everlive.Sdk.$". You can read more about that here.
Here is the proposed security system for your app, based on what you described.
Create role ‘Administrator’. By default there is the ‘Registered’ role that is assigned at the moment of registering of users if they are not assigned to a specific role.
In order to maintain the ‘multiple admins and message to many users in a group’ scenario create the following roles for each group - admin role and user role. For example, for Group1 you will have Group1Admin and Group1User, for Group2 - Group2Admin and Group2User, etc. You can then use those roles to define permissions for the messages. This way you can easily add administrators or users to a group, you just need to set the role of the user, without adjusting the granular permissions of the items in the group. Please note that this concept might not be optimal, if you have many groups - you will have to create many roles. Note however, that you can create roles from the SDK using masterkey access. In Everlive, every user has a single role. This means that with the above concept a user can only have access to a single group, either as an administrator or as normal user.
This type should only be accessible with master key. This means that you should set its security to role-based and manually unselect all roles for all operations from Everlive’s portal (Types > ‘Groups’ > ‘Permissions’ tab). This will ensure that only requests with master key will be allowed.
Content type structure:
This type has an ‘AdminId’ field of type ‘Relation’ to ‘Users’.
Permissions: no permissions or access is granted to anyone, except: ‘Anonymous’ can ‘Create’ (to allow registering), ‘Owner’ can ‘Read’ (to be able to edit your profile).
In the ‘beforeCreate’ event we would like to make the following checks:
- The provided by the user ‘groupId’ is checked and if such group exists the user is created.
- For the created user the ACL ‘UsersCanRead’ is set to the ‘AdminId’ of this group. Thus the administrator will be able to only read the users of his group.
If you decide to maintain multiple admins and messages to many users: when creating users bound them to a certain group. You should set the role of newly created users to the role for that group. For example, if the user is admin of the group, his role should be in GroupXAdmin role. If he is a limited user, he should go to GroupXUser role.
For this type the permissions are also role-based. The only checked option is for the ‘Administrator’ to ‘Create’ a message. This enables only the ‘Administrator’ to create messages. The ‘Owner’ of the message (which is the administrator) will have full access to the message.
The administrator can create messages. When a message is created in the ‘beforeCreate’ event its ACL permissions for ‘UsersCanRead’ and ‘UsersCanDelete’ are allowed for the addressee’s ID.
With the other approach, role-based security should be applied to the Messages type and all roles should be excluded. Creation can only be done with master key. Every message is bound to certain group. When creating the message, its ACL should be set to allow READ from the GroupXUser role and to allow all operations to the GroupXAdmin role.
Please, let us know what you think on both approaches. In case of any other questions, please, do not hesitate to contact us. We would be happy to help.