Administrateur de l’instance¶
L’administrateur fait fonctionner l’instance : comptes, invitations, fournisseurs de connexion et réglages. L’administrateur ne lit pas les logements (ADR 0022).
Qui est administrateur¶
Un compte actif qui est à la fois staff et superuser. Le premier compte d’une nouvelle instance créé par authentification unique en est un (voir Authentification unique) ; manage.py createsuperuser en crée un autre ; le site d’administration (/admin/) accorde ou retire le rôle sur un compte existant (les deux cases, avec audit). Être administrateur n’ajoute aucun logement au compte : il voit les logements dont il fait partie, comme tout le monde.
Ce que l’administrateur peut faire¶
Les comptes, dans le site d’administration : activer ou désactiver un compte, accorder ou retirer le rôle d’administrateur, supprimer un compte. Les modifications et suppressions sont inscrites au journal d’audit de l’instance. Un compte se crée par une invitation à l’instance (ou par l’inscription, ou l’authentification unique, quand l’instance les permet), jamais depuis le site d’administration.
Les invitations à l’instance, sur
/instance/et dans l’API (/api/v1/instance/invitations/) : une adresse reçoit un lien par e-mail, crée un compte puis son propre logement. Elles nécessitent l’envoi d’e-mails. Voir Administration de l’instance.Les fournisseurs et réglages : variables d’environnement (voir Variables d’environnement). Rien ne se modifie dans l’interface.
Le déverrouillage des logements : quand un fournisseur est retiré de la configuration, les logements qui l’exigeaient restent verrouillés. Retirer ces exigences sur la page de l’instance (ou
POST /api/v1/instance/unlock/) efface la règle de tous, sans montrer lesquels. Un propriétaire peut aussi lever la règle de son propre logement depuis sa page verrouillée.Le journal d’audit de l’instance :
/instance/audit/et/api/v1/instance/audit/.
Ce que l’administrateur ne peut pas faire¶
Lire un logement, ses membres, invitations, événements, fichiers ou journal d’audit ; exporter ou supprimer un logement ; recevoir le nom d’un logement. Les pages web et l’API répondent 404 pour un logement dont l’administrateur ne fait pas partie, le site d’administration n’enregistre aucun modèle de logement, et un jeton d’API ne sert jamais les points d’accès de l’administrateur.
La page d’un compte dans le site d’administration ne liste pas ses appartenances, et la suppression d’un compte non plus.
L’administrateur supprime un compte selon les mêmes règles que la personne : l’unique administrateur, et l’unique propriétaire d’un logement qui a d’autres membres, ne peuvent pas être effacés.
L’administrateur ne peut pas prendre un compte. Le site d’administration n’a aucune page pour fixer un mot de passe, affiche l’adresse d’un compte en lecture seule, ne peut pas ajouter de compte et n’enregistre aucun modèle qui détient un identifiant : adresses e-mail, identités liées et clés de fournisseur, secrets d’authentification et codes de récupération, tâches de fond planifiées et terminées. Les jetons d’API sont listés et révoqués, jamais lus. Une personne qui a perdu son accès le récupère avec le lien Mot de passe oublié ?, qu’elle déclenche et qui part vers sa propre adresse ; l’administrateur ne peut ni le faire à sa place ni lire le lien. Sans e-mail sortant, il n’y a pas de tel lien, et l’exploitant de la machine définit un nouveau mot de passe avec
manage.py changepassword.
Ce contre quoi cela ne protège pas¶
Qui exploite la machine lit la base de données et ses sauvegardes, et peut lancer manage.py (changepassword, shell) : la garantie porte sur l’application, pas sur l’hôte. Dites-le aux personnes qui s’inscrivent (politique de confidentialité, sauvegardes, qui a accès au serveur).