Permissions¶
Kinto-Core provides a mechanism to handle authorization on the stored objects.
This section gives details about the behaviour of resources in regards to permissions.
User resource¶
This is the simplest one, as presented in the resource section.
When using a kinto.core.resource.UserResource
, every authenticated user
can manipulate and read their own records. There is no way to restrict this or
allow sharing of records.
Method | URL | permission |
---|---|---|
GET / HEAD | /{collection} | Authenticated |
POST | /{collection} | Authenticated |
DELETE | /{collection} | Authenticated |
GET / HEAD | /{collection}/{id} | Authenticated |
PUT | /{collection}/{id} | Authenticated |
PATCH | /{collection}/{id} | Authenticated |
DELETE | /{collection}/{id} | Authenticated |
Note
When using only these resources, the permission backend remains unused. Its configuration is not necessary.
Public BasicAuth¶
If Basic Auth authentication is enabled, private user resources can become semi-private or public
if the user:pass
is publicly known and shared (for example public:
is a valid user:pass combination).
That’s how most simple demos of Kinto are built by the way!
Backends¶
The ACLs are stored in a permission backend. Like for Storage and Cache, it is pluggable from configuration.
PostgreSQL¶
-
class
kinto.core.permission.postgresql.
Permission
(client, *args, **kwargs)¶ Permission backend using PostgreSQL.
Enable in configuration:
kinto.permission_backend = kinto.core.permission.postgresql
Database location URI can be customized:
kinto.permission_url = postgres://user:pass@db.server.lan:5432/dbname
Alternatively, username and password could also rely on system user ident or even specified in
~/.pgpass
(see PostgreSQL documentation).Note
Some tables and indices are created when
kinto migrate
is run. This requires some privileges on the database, or some error will be raised.Alternatively, the schema can be initialized outside the python application, using the SQL file located in
kinto/core/permission/postgresql/schema.sql
. This allows to distinguish schema manipulation privileges from schema usage.A connection pool is enabled by default:
kinto.permission_pool_size = 10 kinto.permission_maxoverflow = 10 kinto.permission_max_backlog = -1 kinto.permission_pool_recycle = -1 kinto.permission_pool_timeout = 30 kinto.cache_poolclass = kinto.core.storage.postgresql.pool.QueuePoolWithMaxBacklog
The
max_backlog
limits the number of threads that can be in the queue waiting for a connection. Once this limit has been reached, any further attempts to acquire a connection will be rejected immediately, instead of locking up all threads by keeping them waiting in the queue.See dedicated section in SQLAlchemy documentation for default values and behaviour.
Note
Using a dedicated connection pool is still recommended to allow load balancing, replication or limit the number of connections used in a multi-process deployment.
Noindex:
Redis¶
-
class
kinto_redis.permission.
Permission
(client, *args, **kwargs)¶ Permission backend implementation using Redis.
Enable in configuration:
kinto.permission_backend = kinto_redis.permission
(Optional) Instance location URI can be customized:
kinto.permission_url = redis://localhost:6379/2
A threaded connection pool is enabled by default:
kinto.permission_pool_size = 50
Noindex:
API¶
Implementing a custom permission backend consists in implementating the following interface: