Le fondateur : « la mise à l'abri des vidéos ne fonctionne pas ». Mesuré depuis un poste contre le déploiement (PARCOURS_CIBLE=homelab bun run test:televersement de kadans) : une vidéo qui tient en une part arrive ; une vidéo en deux parts échoue à POST …/depot/confirmer → 502 {"error":"stockage injoignable"}, en 36 ms, deux fois sur deux.
Rejoué avec les identifiants de kadans-api (kvv2/minio/kadans, jamais affichés), par la même bibliothèque (minio-go v7.2.1) et les mêmes options que stockage.go, dans trois configurations (contrôle par l'endpoint interne + parts par URL présignée = le chemin exact de l'API ; contrôle par l'endpoint public ; parts déposées par le client interne) :
NewMultipartUpload → OK
PUT part 1, part 2 → 200 (ETag présents)
ListObjectParts → 403 AccessDenied
AbortMultipartUpload → 403 AccessDenied
Ouvrir un téléversement et déposer ses parts sont des s3:PutObject — accordés. Lister les parts exige s3:ListMultipartUploadParts et abandonner exige s3:AbortMultipartUpload — absents de la politique ${app}-app de ce module. L'app ne pouvait donc jamais refermer un téléversement en parts : toute vidéo de plus d'une part (8 Mio côté kadans, soit environ une minute de cours à 360p) échouait à l'assemblage, à tous les coups, depuis n'importe quel appareil. Et faute d'Abort, ce qu'elle ouvrait restait jusqu'à la règle de cycle de vie à un jour — vraisemblablement les « octets ×2,7 trop lourds » de kadans-api#107.
Le changement
Deux actions de plus sur les OBJETS des buckets de l'app, rien d'autre : s3:ListMultipartUploadParts, s3:AbortMultipartUpload. Le README dit désormais ce que le compte de service peut faire d'un téléversement en parts. tofu fmt -check : propre.
Après la fusion
Le module est référencé sur main (?depth=1&ref=main) par l'iac/ de kadans : c'est le workflow vault.yaml de kadans (Tofu, workflow_dispatch) qui applique la politique. Preuve attendue ensuite : PARCOURS_CIBLE=homelab bun run test:televersement passe 4/4 (aujourd'hui 1/4).
## Le défaut, mesuré le 2026-09-07 sur le homelab
Le fondateur : *« la mise à l'abri des vidéos ne fonctionne pas »*. Mesuré depuis un poste contre le déploiement (`PARCOURS_CIBLE=homelab bun run test:televersement` de `kadans`) : une vidéo qui tient en une part arrive ; **une vidéo en deux parts échoue à `POST …/depot/confirmer` → 502 `{"error":"stockage injoignable"}`**, en 36 ms, deux fois sur deux.
Rejoué avec les identifiants de `kadans-api` (`kvv2/minio/kadans`, jamais affichés), par la même bibliothèque (`minio-go v7.2.1`) et les mêmes options que `stockage.go`, dans trois configurations (contrôle par l'endpoint interne + parts par URL présignée = le chemin exact de l'API ; contrôle par l'endpoint public ; parts déposées par le client interne) :
```
NewMultipartUpload → OK
PUT part 1, part 2 → 200 (ETag présents)
ListObjectParts → 403 AccessDenied
AbortMultipartUpload → 403 AccessDenied
```
Ouvrir un téléversement et déposer ses parts sont des `s3:PutObject` — accordés. **Lister les parts exige `s3:ListMultipartUploadParts` et abandonner exige `s3:AbortMultipartUpload`** — absents de la politique `${app}-app` de ce module. L'app ne pouvait donc jamais refermer un téléversement en parts : toute vidéo de plus d'une part (8 Mio côté kadans, soit environ une minute de cours à 360p) échouait à l'assemblage, à tous les coups, depuis n'importe quel appareil. Et faute d'`Abort`, ce qu'elle ouvrait restait jusqu'à la règle de cycle de vie à un jour — vraisemblablement les « octets ×2,7 trop lourds » de kadans-api#107.
## Le changement
Deux actions de plus sur les OBJETS des buckets de l'app, rien d'autre : `s3:ListMultipartUploadParts`, `s3:AbortMultipartUpload`. Le README dit désormais ce que le compte de service peut faire d'un téléversement en parts. `tofu fmt -check` : propre.
## Après la fusion
Le module est référencé sur `main` (`?depth=1&ref=main`) par l'`iac/` de `kadans` : c'est le workflow **`vault.yaml` de `kadans`** (Tofu, `workflow_dispatch`) qui applique la politique. Preuve attendue ensuite : `PARCOURS_CIBLE=homelab bun run test:televersement` passe 4/4 (aujourd'hui 1/4).
Issue : https://gitea.arcodange.lab/arcodange/kadans/issues/1033
🤖 Generated with [Claude Code](https://claude.com/claude-code)
`ListObjectParts` et `AbortMultipartUpload` rendaient 403 AccessDenied avec les
identifiants de kadans-api — mesuré le 2026-09-07 sur le homelab, en rejouant les
appels de contrôle exacts de l'API depuis un poste. Ouvrir et déposer les parts
sont des PutObject et passaient ; l'assemblage n'a jamais pu avoir lieu, et toute
vidéo de plus d'une part échouait à la confirmation derrière « stockage injoignable ».
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Le défaut, mesuré le 2026-09-07 sur le homelab
Le fondateur : « la mise à l'abri des vidéos ne fonctionne pas ». Mesuré depuis un poste contre le déploiement (
PARCOURS_CIBLE=homelab bun run test:televersementdekadans) : une vidéo qui tient en une part arrive ; une vidéo en deux parts échoue àPOST …/depot/confirmer→ 502{"error":"stockage injoignable"}, en 36 ms, deux fois sur deux.Rejoué avec les identifiants de
kadans-api(kvv2/minio/kadans, jamais affichés), par la même bibliothèque (minio-go v7.2.1) et les mêmes options questockage.go, dans trois configurations (contrôle par l'endpoint interne + parts par URL présignée = le chemin exact de l'API ; contrôle par l'endpoint public ; parts déposées par le client interne) :Ouvrir un téléversement et déposer ses parts sont des
s3:PutObject— accordés. Lister les parts exiges3:ListMultipartUploadPartset abandonner exiges3:AbortMultipartUpload— absents de la politique${app}-appde ce module. L'app ne pouvait donc jamais refermer un téléversement en parts : toute vidéo de plus d'une part (8 Mio côté kadans, soit environ une minute de cours à 360p) échouait à l'assemblage, à tous les coups, depuis n'importe quel appareil. Et faute d'Abort, ce qu'elle ouvrait restait jusqu'à la règle de cycle de vie à un jour — vraisemblablement les « octets ×2,7 trop lourds » de kadans-api#107.Le changement
Deux actions de plus sur les OBJETS des buckets de l'app, rien d'autre :
s3:ListMultipartUploadParts,s3:AbortMultipartUpload. Le README dit désormais ce que le compte de service peut faire d'un téléversement en parts.tofu fmt -check: propre.Après la fusion
Le module est référencé sur
main(?depth=1&ref=main) par l'iac/dekadans: c'est le workflowvault.yamldekadans(Tofu,workflow_dispatch) qui applique la politique. Preuve attendue ensuite :PARCOURS_CIBLE=homelab bun run test:televersementpasse 4/4 (aujourd'hui 1/4).Issue : arcodange/kadans#1033
🤖 Generated with Claude Code