# 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](/fr/docs/table-permissions) : 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.                                      |

```yaml
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. |

:::callout
**Traitez `upload` / `download` / `delete` comme une intention, pas comme une barrière — pour l'instant.** Écrivez-les : ils consignent dans le schéma ce que vous vouliez, ils survivent à `sovrium validate`, et ils sont exactement ce que le chemin d'application lira. Mais ne placez pas un bucket privé derrière une liste de rôles en supposant qu'un `member` ne peut aujourd'hui pas y téléverser. Si une frontière doit tenir dès maintenant, exprimez-la avec `public: false` et le [flux d'URL signées](/fr/docs/signed-urls), dont les permissions _sont_ vérifiées.
:::

## 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](/fr/docs/buckets-overview) — le bucket auquel appartient un bloc de permissions.
- [Backends de stockage](/fr/docs/buckets-backends) — où les octets autorisés sont écrits.
- [URL signées](/fr/docs/signed-urls) — le flux qui lit `sign` et `signUpload`.
- [Rôles et RBAC](/fr/docs/auth-roles-rbac) — d'où viennent les noms de rôles.
- [Permissions de table](/fr/docs/table-permissions) — le même format de valeur sur les tables.