Nouvelle colonne max_photos_per_guest (NULL = illimité). Appliquée via un guest_id anonyme persisté en localStorage — pas une identité vérifiée, contournable en changeant d'appareil, mais fait respecter côté serveur (source de vérité) et bloque l'UI proactivement côté client. Ancienne signature de insert_public_photo (sans guest_id) supprimée pour empêcher tout contournement. Testé en conditions réelles sur kevin-lecou-hub (2 photos acceptées, 3e refusée avec max_photos_per_guest=2).
4.4 KiB
4.4 KiB
Journal des décisions
Ce fichier consigne les décisions structurantes actées pour le projet, avec la date à laquelle elles ont été prises. Toute nouvelle décision structurante (schéma DB, auth, hébergement, etc.) doit être ajoutée ici après validation par Kévin.
2026-09-15
- Expiration des données : suppression à J+7 à partir de la date de
l'événement (
date_evenement), et non à partir de la date de création de l'événement dans le système. - Sécurité admin (V1) : accès à la galerie admin via un token secret
dans l'URL (
admin_token), pas de système de login/mot de passe. Réévaluer ce choix avant V2/V3 si le nombre de clients augmente. - Suppression des données : effective à J+7 dans tous les cas, y compris si l'organisateur a déjà téléchargé le ZIP d'export des photos.
- Hébergement : utilisation du VPS existant de Kévin (148.230.114.175), pas de nouvel hébergement dédié pour l'instant.
2026-09-16
- Compression image côté client : utilisation de la lib
browser-image-compression, plutôt qu'une implémentation maison via Canvas API. Doit gérer l'orientation EXIF et les formats HEIC (iPhone).
2026-09-15 (bis)
- Préfixage des tables : le projet Supabase de photobooth-qr sera
mutualisé avec les autres projets de Kévin (KOMI, KAZA...). Tables
préfixées
pq_(pq_events,pq_photos), conformément à la convention du CLAUDE.md global. Les fonctions Postgres exposées au front (get_public_event,event_accepts_uploads) restent sans préfixe : ce sont des points de contrat public, pas des tables internes. - Bucket Supabase Storage
event-photos: bucket privé (pas de lecture publique). Convention de chemin :{event_id}/{uuid}.{ext}. Consultation admin exclusivement via URLs signées générées par l'Edge Functionservice_role. Aucune policy SELECT/UPDATE/DELETE publique surstorage.objects. Limité àfile_size_limit = 6 Moetallowed_mime_types = image/jpeg(aligné sur la sortie de compression du front, qui force tout en JPEG y compris les HEIC convertis). pq_photos.url_storage: contrainteCHECKgarantissant que le chemin commence parevent_id/, pour empêcher qu'une ligne de l'event A pointe vers un fichier de l'event B (isolation multi-tenant), trouvé lors de la relecture sécurité du 2026-09-15.get_public_event: renvoie l'événement même si son statut n'est pasactif(expiré/archivé), pour permettre au front d'afficher un message adapté. Risque jugé faible : les slugs sont partagés via QR code, donc non secrets par nature.
2026-09-16 (quater)
- Limite de photos par invité : nouvelle colonne
photobooth.events.max_photos_per_guest(NULL = illimité par défaut), réglable uniquement en SQL à la création de l'event pour l'instant (pas d'UI admin dédiée). Appliquée via unguest_idanonyme généré et persisté côté client (localStorage) — pas une identité vérifiée, contournable en changeant d'appareil ou en vidant le storage. Fait respecter côté serveur (RPCinsert_public_photo, source de vérité) et côté client de façon proactive (évite un envoi pour se le faire refuser à la dernière étape).
2026-09-16 (ter)
- Domaine de production (V1) :
photobooth.assistantaikev.eu, sous-domaine du domaine déjà utilisé pour n8n. Décision explicitement temporaire : à déplacer vers un domaine dédié en V2/V3 si le produit est vendu sous sa propre marque. Front servi par un container nginx sur le VPS existant (Traefik/Let's Encrypt déjà en place pour n8n), config dansdeploy/.APP_BASE_URLconfigurée comme secret sur les 2 Edge Functions pour le CORS. Déploiement testé en conditions réelles le 2026-09-16 (upload + galerie admin fonctionnels depuis le domaine public).
2026-09-16 (bis)
- Déclenchement de la purge Storage à J+7 : option n8n retenue
(plutôt que
pg_cron+pg_net). Un workflow n8n planifié quotidien appelle l'Edge Functionexpire-eventsavec laservice_rolekey (Credentials Store n8n), avec notification Telegram en cas d'échec. Cohérent avec la stack n8n déjà utilisée pour KOMI/KAZA, et le VPS n8n existant sert de point d'orchestration commun. Conception du workflow :n8n/workflows/purge-storage-j7.json(JSON importable, non testé sur l'instance n8n réelle, credentials à relier manuellement avant activation).