readprivilege on messages that allow anyone holding that privilege to read the message.
participant(channel-id:status)which denotes the set of all users that are participants in
statusas their Participation status.
TimelineEventare all ACL entities.
msgsent to a channel with id
chnlby the user
Messageis an ACL entity to which the following privileges can be applied:
axenow wanted to send a message to the channel that only
rylaicould read, he would send the message with his custom ACLs:
rylais device and only she will see it when she fetches messages via HTTP.
axewants to send a message to everyone in the channel except
rylaihas been acting way too cool recently. To do so, he can set the ACLs as:
p-listconsists of all ACLs that have a
+permission and similarly the
m-listconsists of all ACLs that have a
-permission. To check whether a given user has access to a privilege on an entity, we check if:
-read:participant(chnl)would still result in the
readprivilege not being granted to
p-listresults in no privileges being granted to any user. This however is not permitted in the system due to default ACLs and sticky ACLs kicking in, which is covered further below.
.systemhas complete access of all the data of the application. Moreoever, certain privileges, like
-revoke_tokens_for_selfis a privilege that a user is always granted and this cannot be overriden. To keep these constants in place, there are two ACL lists that are maintainted for each entity:
+add_participant:user(.system)which means that you can always add a participant to any channel using an application key/secret.
user(user-id)Represents a single user having the provided id.
participant(channel-id:status)Represents the group of users which are a participant in the channel with the given channel id, with a particular participation status.
any_user()Represents any authenticated user.
aclTagand all users belonging to an acl tag can be selected using
Usercoming up in the next release. We will also be releasing partial access to ACLs on
Applicationvia certain configuration options in the subscriber panel.
join_channelJoin the channel (add oneself)
add_participant_to_channelAdd any other user as a participant to the channel
list_participantsList the participants of the channel
remove_participantRemove any other user as a participant to the channel
remove_selfRemove oneself from the channel
delete_messages_from_channelDelete messages from the channel
read_from_channelRead the channel object and send messages to it
send_to_channelSend messages to the channel with themselves as the sender
send_as_other_to_channelSend messages to the channel with anyone else as the sender
adminfor the channel, who alone can add participants to the channel, but anyone could remove themsleves, you would assign the following privileges to channel:
participant(chnl:status), but for the sake of brevity we have omitted it. Similarly, the actual privileges on messages are
read_messageRead the message
delete_messageDelete the message
read_from_channelprivilege on the channel the message was sent to.
create_channel- Create a channel
create_message- Create a message
create_user- Create a user
list_channels- List all the channels in the application
list_user_data- List the user data for a user (other than oneself)
write_user_credentials- Revoke/Issue tokens for a user (other than oneself)
OutOfBandmessages and is currently not applied or in use anywhere. The privilege
list_channelsis required to list the channels in an application, but only those channels will be returned for which the user has a
read_from_channelprivilege. The subtle difference that manifests is that if the user does not have that privilege on any channel, this call will return an empty list, but if the user does not have
list_channelsprivilege, it will return a
403 Forbidden(with a
missing_privilegeserror code). A user can not have the
list_channelsprivilege but still send and receive messages to a channel for which they have the appropriate
.systemcannot list user data for itself or issue user tokens for itself.
PatchType.Setoperation overwrites all ACLs for a given entity as is specified in the payload. A
PatchType.Diffoperation on the other hand specifies the specific ACLs that are to be added/removed for an entity.
joinprivilege from every user. Do note that a user can still add some other participant to the channel, since the
add_participantprivilege is still available to them. Ideally, we should have revoked both the permissions, but for the sake of brevity we will continue with this example with the single privilege.
-join:any_user()rule from the channel.
Difftype of ACL modification:
Settype operation and instead do:
Applicationto be modified (or specified up-front for that matter).