Permissions de bucket

Le bloc permissions d'un bucket répond à une question par opération : qui a le droit de faire cela ? Il emploie le même format PermissionValue à trois formes que les permissions de table : rien de nouveau à apprendre pour le lire.

Valeur	Signification
all	Tout le monde, y compris les requêtes non authentifiées.
authenticated	Tout utilisateur disposant d'une session, quel que soit son rôle.
[admin, editor]	Uniquement les rôles listés.

buckets:
  - name: documents
    maxFileSize: 52428800
    allowedMimeTypes: [application/pdf, text/csv]
    permissions:
      upload: [admin, editor]
      download: authenticated
      sign: authenticated
      signUpload: [admin, editor]
      delete: [admin]

Les cinq opérations

Opération	Régit	Défaut si omis
upload	L'écriture d'un nouveau fichier dans le bucket.	authenticated
download	La relecture d'un fichier.	all sur un bucket public, authenticated sinon
sign	L'émission d'une URL signée de téléchargement.	[admin]
signUpload	L'émission d'une URL signée de téléversement.	[admin]
delete	La suppression d'un fichier du stockage.	[admin]

Omettre entièrement permissions applique tous les défauts ci-dessus. La conséquence à retenir : la signature est réservée aux administrateurs tant que vous n'en décidez pas autrement. Un bucket dont un member doit pouvoir distribuer des liens de téléchargement exige un sign: authenticated écrit noir sur blanc ; le silence vaut refus.

Ce qui est appliqué aujourd'hui

sign et signUpload sont appliqués par les points de terminaison de signature, avec résolution du rôle et dérogation administrateur. Les trois autres sont déclarés dans le schéma mais ne sont pas encore consultés par les routes de fichiers, qui s'appuient sur l'indicateur public du bucket et sur la présence d'une session :

Requête	Réponse
Téléversement ou suppression sur un bucket public	Autorisé, avec ou sans session.
Téléversement ou suppression sur un bucket privé	401 sans session ; autorisé avec.
Téléchargement sur un bucket privé, sans session	404 (anti-énumération — jamais 403).
Signature sans session	401.
Signature avec session mais sans permission correspondante	404, pour que la frontière de permission reste invisible.

Dérogation administrateur et appelants anonymes

Deux règles traversent toutes les vérifications de signature :

• admin passe toujours. Un rôle nommé admin peut signer sur n'importe quel bucket, quelle que soit la permission déclarée.
• all exige malgré tout une session sur les points de terminaison de signature. Les routes de signature rejettent les appelants anonymes avec 401 avant toute évaluation de permission : sign: all élargit donc l'accès à tout utilisateur connecté, pas au public. Pour servir des fichiers sans session, utilisez public: true — c'est là le commutateur des lectures anonymes.

Pages associées

• Présentation des buckets — le bucket auquel appartient un bloc de permissions.
• Backends de stockage — où les octets autorisés sont écrits.
• URL signées — le flux qui lit sign et signUpload.
• Rôles et RBAC — d'où viennent les noms de rôles.
• Permissions de table — le même format de valeur sur les tables.