As described in the concepts section <concepts-permissions>
, permissions can be set on any object.
On each kind of object the set of permissions can be:
Permission | Description |
---|---|
read | Any listed principal can read the object. |
write | Any listed principal can write the object, which further implies read, update, and delete. |
create | Any listed principal can create a new child object. |
In the case of a creation, since an object can have several kinds of children, the permission is prefixed by the type of child (for instance group:create
, collection:create
).
The following table lists all permissions that can be associated to each kind of object.
Object | Associated permissions | Description |
---|---|---|
Configuration | bucket:create |
Create new buckets. |
Bucket |
|
|
Collection |
|
|
Record |
|
|
Group |
|
|
Every modification of an object (including the creation of new objects) grant the write permission to their creator.
Note
There is no delete
permission. Anyone with the write
permission on an object can delete it.
During the authentication phase, a set of principals
for the current authenticated user will be bound to to the request.
The main principal is considered the user ID and follows this formalism: {type}:{identifier}
(e.g. for Firefox Account: fxa:32aa95a474c984d41d395e2d0b614aa2
).
There are two special principals:
system.Authenticated
: All authenticated users.system.Everyone
: Anyone (authenticated or anonymous). Using this principal is useful when a rule should apply to all users.
Note
A user can also be another application (in order to provide service to service authentication).
The currently authenticated user ID can be obtained on the root URL.
$ http GET http://localhost:8888/v1/ --auth token:my-secret
HTTP/1.1 200 OK
Access-Control-Expose-Headers: Backoff, Retry-After, Alert, Content-Length
Content-Length: 288
Content-Type: application/json; charset=UTF-8
Date: Thu, 16 Jul 2015 09:48:47 GMT
Server: waitress
{
"documentation": "https://kinto.readthedocs.io/",
"hello": "cloud storage",
"settings": {
"kinto.batch_max_requests": 25
},
"url": "http://localhost:8888/v1/",
"user": {
"id": "basicauth:631c2d625ee5726172cf67c6750de10a3e1a04bcd603bc9ad6d6b196fa8257a6"
},
"version": "1.4.0"
}
In this case the user ID is: basicauth:631c2d625ee5726172cf67c6750de10a3e1a04bcd603bc9ad6d6b196fa8257a6
Note
If Alice wants to share objects with Bob, Bob will need to give Alice his user ID - this is an easy way to obtain that ID.
An object's permissions can be modified at the same time as the object itself, using the same PATCH <record-patch>
and PUT
<record-put>
methods discussed in the Records section
<records>
.
Note
The user ID that updates any permissions is always added to the write
permission list. This is in order to prevent accidental loss of ownership on an object.
Requires setting kinto.experimental_permissions_endpoint
to True
.