Files
photobooth-qr/supabase/migrations/20260916090300_enable_rls.sql
KevinLecou 9b1461978b Ajoute la V1 fonctionnelle : upload invité, galerie admin, QR code, backend Supabase
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).
2026-09-16 11:32:31 +02:00

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.