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).
35 lines
2.0 KiB
SQL
35 lines
2.0 KiB
SQL
-- Migration : activation RLS sur photobooth.events / photobooth.photos
|
|
-- Réf. : docs/modele-donnees.md (section "Row Level Security (RLS)")
|
|
--
|
|
-- ⚠️ Ne pas appliquer depuis cet agent (Kévin applique lui-même).
|
|
|
|
alter table photobooth.events enable row level security;
|
|
alter table photobooth.photos enable row level security;
|
|
|
|
-- Choix DÉLIBÉRÉ : AUCUNE policy sur photobooth.events ni photobooth.photos,
|
|
-- pour anon/authenticated/service_role — ni SELECT, ni INSERT, ni UPDATE, ni
|
|
-- DELETE. RLS activé + zéro policy = accès refusé par défaut pour tout rôle
|
|
-- non-BYPASSRLS.
|
|
--
|
|
-- Pourquoi (documenté suite à la consigne "garde la policy d'INSERT anon si
|
|
-- tu juges ça utile, sinon documente pourquoi tu la retires") : dans cette
|
|
-- architecture, le schéma `photobooth` n'est de toute façon JAMAIS exposé
|
|
-- via PostgREST (cf. 20260916090000_create_photobooth_schema.sql) — aucune
|
|
-- route REST n'existe pour `photobooth.photos`, donc une policy anon INSERT
|
|
-- ne servirait à rien en temps normal (personne ne peut l'atteindre par ce
|
|
-- chemin). Le SEUL chemin d'écriture pour anon est désormais la fonction
|
|
-- SECURITY DEFINER public.insert_public_photo(), qui revalide elle-même
|
|
-- event_accepts_uploads() et la cohérence url_storage/event_id avant
|
|
-- d'insérer (cf. 20260916090400_create_public_functions.sql) — et une
|
|
-- fonction SECURITY DEFINER s'exécute avec les privilèges de son
|
|
-- propriétaire, PAS ceux de l'appelant : elle n'a donc pas besoin d'une
|
|
-- policy RLS permissive pour anon afin de fonctionner.
|
|
--
|
|
-- Garder RLS activé SANS policy sert uniquement de filet de sécurité en cas
|
|
-- d'erreur humaine future (ex. quelqu'un ajoute `photobooth` aux "Exposed
|
|
-- schemas" par erreur un jour) : dans ce scénario, sans policy, un accès
|
|
-- REST direct resterait refusé pour anon/authenticated. Ajouter UNE policy
|
|
-- anon INSERT "juste au cas où" recréerait exactement le chemin
|
|
-- d'écriture non revalidé qu'on vient de fermer avec
|
|
-- public.insert_public_photo() — jugé contre-productif, donc pas ajoutée.
|