Basically, Kinto is a service where client applications can store and retrieve JSON data.
In order to provide synchronisation and sharing features for these data, Kinto introduces some basic concepts.
Kinto objects in brief :
|bucket||Buckets can be seen as namespaces: collection names won’t collide if stored in different buckets.|
|collection||A collection of records|
|record||The actual stored data|
|group||A named list of principals to define permissions.|
Buckets, Collections, and Records¶
A record is the smallest unit of data. By default, there is no schema, and the JSON can contain anything.
A collection is a group of records. Records are manipulated as a list and can be filtered or sorted. Clients can obtain the list of changes that occured on the collection records since a certain revision (e.g. last synchronisation).
A bucket is an abstract notion used to organize collections and their
permissions. A bucket named
default is provided, whose collections and records
are accessible to the current user only.
Every kind of object manipulated by Kinto shares some common properties:
- A unique identifier.
- A revision number, automatically incremented on change.
- A set of permissions.
Those concepts are very similar to a hard disk, where buckets would be partitions, collections are folders, and records are files!
Kinto has a concept of groups of users. A group has a list of members and belongs to a bucket.
Permissions can refer to the group instead of an individual user - this makes it easy to define “roles”, especially if the same set of permissions is applied to several objects.
In order to control who is allowed to read, create, modify, or delete the records, permissions can be defined on buckets, groups, collections, and single records.
Since there is a notion of hierarchy between buckets, collections, and records, Kinto considers permissions as inherited from parent objects.
For example, if a bucket defines a permission that allows anonymous users to read, then every record of every collection in this bucket will also be readable, as a result of inheritance.
The permission to create new objects is defined in the parent. For example, the permission to create records is defined in the collection, and the permission to create collections or groups is defined in the bucket. The permission to create new buckets, however, is controlled from the server configuration.
If a parent defines a permission, it is (currently) not possible to restrict it in its child objects.
Regarding permissions, the following vocabulary is used in the documentation:
- An entity that can be authenticated. Principals can be individual people,
applications, services, or any group of such things
- A permission is an action that can be performed on an object. Examples of permissions are “read”, “write”, or “create”.
- The subject on which a permission is applied. Buckets, Collection, and Records are examples of objects.
Access Control Entity
- An ACE associates a permission to both objects and principals.
This allows you to describe rules like “Members of group admins can
create collections” (e.g
collections:create = ['group:admins',]).
Access Control List
- A list of ACEs.
- Firefox Accounts
- Account system run by Mozilla (https://accounts.firefox.com).
- User id
- A string that identifies a user.
Check out our blog post on permissions in Kinto for more information.