---
title: Socle de stockage — URL d'envoi signée et ingestion serveur
area: backend manager
horizon: v2
tags: manager-service, manager-app, Studio IA, sécurité
flag: critical | Prérequis dur
src: v2/studio-plan.md — §8 lot 0, décisions 14, 18, 20
---
<p><code>IResourceBlobService</code> n'expose que <code>DeleteAsync</code> : <strong>tout l'upload est fait par le navigateur en direct</strong>, à deux endroits de <code>resources_screen.dart</code>. Or le Studio et le TTS pré-généré produiront côté serveur.</p>
<p>⚠️ <strong>Trou de sécurité actuel, indépendant du Studio.</strong> manager-app n'a pas de Firebase Auth (<code>firebase_storage</code> sans <code>firebase_auth</code>) et écrit pourtant dans le bucket : les règles Storage sont très probablement <strong>ouvertes en écriture</strong>. Aucun <code>storage.rules</code> dans le repo — à relever dans la console.</p>
<p>✅ <strong>Tranché le 13/09 : URL signée + ingestion.</strong> L'API délivre une URL V4 signée (15 min, un objet, taille bornée), le navigateur envoie directement chez Google dans <code>incoming/</code>, puis <code>POST /ingest</code> : un <code>ResourceIngestionService</code> unique — le même pour le Studio et le TTS — mesure la <strong>taille réelle</strong>, applique quota et plafond, post-traite les images (2 à la fois au plus) et range sous <code>pictures/</code>. Les vidéos, 360 et GLB sont copiés côté Google, jamais lus par le VPS. Les écritures clientes sont ensuite fermées dans les règles.</p>
<p>Infra : CORS du bucket pour le <code>PUT</code>, règle de cycle de vie à 1 jour sur <code>incoming/</code>, et fermeture des règles <strong>après</strong> le déploiement du nouveau manager-app. À caser dans le même lot : suppression de la route <code>upload</code> morte et d'<code>ImageHelper</code>, <code>Firebase:StorageBucket</code> renseigné, et <strong><code>LB</code> (luxembourgeois)</strong>.</p>