KevinLecou
9b1461978b
Schéma dédié `photobooth` (jamais exposé via PostgREST, accès exclusivement via fonctions SECURITY DEFINER dans public) avec RLS, policies Storage sur bucket privé event-photos, Edge Functions admin-gallery et expire-events, et job pg_cron d'expiration J+7. Le tout déployé et testé en conditions réelles sur le projet Supabase kevin-lecou-hub avant relecture sécurité (faille d'abus sur insert_public_photo corrigée en cours de route). Côté front : page upload invité (compression + HEIC + RGPD), galerie admin avec export ZIP, générateur de QR code autonome. Workflow n8n de purge Storage J+7 fourni (à activer manuellement côté n8n).
39 lines
2.3 KiB
SQL
39 lines
2.3 KiB
SQL
-- Migration : schéma dédié `photobooth`
|
|
--
|
|
-- Changement d'architecture (décision actée avec Kévin, 2026-09-16) :
|
|
-- le projet Supabase définitif ("kevin-lecou-hub", ref ctveboqnbatwmadwsnvw)
|
|
-- est mutualisé avec de futurs produits. Plutôt qu'un préfixe `pq_` sur des
|
|
-- tables dans `public` (approche de la veille), on isole désormais
|
|
-- photobooth-qr dans son propre schéma Postgres `photobooth`. Les tables
|
|
-- s'appellent donc simplement `events` / `photos` (sans préfixe), l'isolation
|
|
-- venant du schéma et non plus du nom de table.
|
|
--
|
|
-- Contrainte technique actée : exposer un schéma custom via l'API REST
|
|
-- (PostgREST) nécessite un réglage MANUEL dans le dashboard Supabase
|
|
-- ("Exposed schemas", Project Settings > Data API) — impossible à faire en
|
|
-- SQL pur. Décision : ne JAMAIS faire ce réglage pour `photobooth`. Ce
|
|
-- schéma reste **totalement privé, jamais exposé via PostgREST** — ni pour
|
|
-- `anon`, ni pour `service_role` (l'exposition de schéma chez PostgREST est
|
|
-- un filtre au niveau du routage HTTP, indépendant du rôle appelant : même
|
|
-- avec la service_role key, un accès REST direct à `photobooth.events`
|
|
-- n'aurait aucune route pour y répondre).
|
|
--
|
|
-- Tout accès (anon ET service_role) passe donc exclusivement par des
|
|
-- fonctions SECURITY DEFINER dans le schéma `public` (qui, lui, reste
|
|
-- exposé par défaut) — cf. 20260916090400_create_public_functions.sql.
|
|
--
|
|
-- ⚠️ Ne pas appliquer depuis cet agent : Kévin applique lui-même via son
|
|
-- accès MCP Supabase direct une fois la relecture faite.
|
|
|
|
create schema if not exists photobooth;
|
|
|
|
comment on schema photobooth is
|
|
'Schéma dédié au projet photobooth-qr (mariage/soirée, galerie photo par QR code). JAMAIS ajouté aux "Exposed schemas" (Project Settings > Data API) : aucun accès direct via PostgREST, ni anon ni service_role. Tout accès passe par des fonctions SECURITY DEFINER dans public.';
|
|
|
|
-- Défensif / documentaire plutôt que strictement nécessaire : un schéma
|
|
-- nouvellement créé n'accorde par défaut AUCUN privilège à PUBLIC (ce
|
|
-- comportement spécial n'existe que pour le schéma `public` historique).
|
|
-- On le rend explicite pour que l'intention soit lisible sans dépendre de
|
|
-- ce détail de comportement Postgres.
|
|
revoke all on schema photobooth from public;
|