tripoli.cloud/app/README.md

40 lines
1.8 KiB
Markdown
Raw Permalink Normal View History

Frontend et backend entièrement réels : plus aucune donnée simulée À la demande explicite de l'utilisateur après avoir constaté que tripoli.cloud affichait un 404 vide (le frontend n'avait jamais été déployé) : déploiement du frontend, puis remplacement complet des mocks par de vraies données, des deux côtés. Backend (tripoli-api) : - users.name, files.category (file/photo/backup), table notifications (migration 0002). - POST /api/auth/guest : compte invité réel et réutilisé (invite@tripoli.local), pas une identité simulée côté frontend. - GET /api/files?category=... , GET /api/notifications (+ read-all/ {id}/read), GET /api/storage (used_bytes réel, available_bytes via statvfs - jamais un quota inventé). - Notifications émises réellement sur upload/suppression. Frontend (app/) : - src/api/*.ts appellent réellement tripoli-api (plus de mockFetch). - Upload réel (XHR, vraie progression), suppression avec bouton dédié, vraies miniatures photo (<img src="/api/files/:id">). - Session restaurée au chargement (GET /api/auth/me), logout réel. - Retiré plutôt que simulé : 2FA, clé de récupération, accès partagés, albums, dossiers, "4 appareils sauvegardés", chiffres marketing et claim AES-256 côté client sur la page de connexion (jamais vrai - remplacé par le vrai : HTTPS + Argon2). Déploiement : - Frontend construit et déployé sur le serveur (le build local échouait spécifiquement sur cette machine - rolldown/esbuild natif ne répondait plus, cause non résolue ; contourné en buildant sur le serveur, comme déjà fait pour les crates Rust). - Caddy : /var/www/tripoli-cloud servi en statique pour tripoli.cloud, /api/*, /healthz, /metrics toujours proxyés vers tripoli-edge. - Pipeline CI étendu : le job deploy construit et déploie maintenant aussi le frontend, via un script sudo dédié supplémentaire (tripoli-deploy-frontend.sh) sur le compte deploy sans privilège. - Vérifié en navigateur réel (Chrome) : inscription, connexion, invité, upload avec progression, photos, sauvegardes, notifications, suppression, déconnexion - tous testés en conditions réelles. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 18:19:51 +02:00
# Tripoli Cloud — frontend
React + TypeScript + Vite + Tailwind. Appelle réellement `tripoli-api`
via `/api/...` (même origine, servi par le Caddy partagé - voir le
README racine) : plus aucune donnée simulée.
## Ce qui est réel
- Auth : inscription, connexion, invité (compte réel réutilisé),
session persistée par cookie, restaurée au chargement.
- Fichiers : upload réel (XHR, vraie progression), téléchargement,
suppression, filtré par catégorie (`file`/`photo`/`backup`).
- Photos : grille des fichiers catégorie `photo`, vraies miniatures
(`<img src="/api/files/:id">`), pas de génération de miniature à part.
- Sauvegardes : fichiers catégorie `backup` - pas de suivi
multi-appareils (aucun agent client n'existe).
- Espace disque : `used_bytes` réel (somme des fichiers), `available_bytes`
réel (`statvfs` côté serveur) - jamais un quota inventé.
- Notifications : émises par le serveur à chaque upload/suppression.
- Réglages : section Compte depuis le vrai utilisateur ; préférences de
notification dans `localStorage` (device-local, pas synchronisé -
annoncé comme tel, pas simulé comme synchronisé).
## Ce qui a été retiré (pas simulé)
La maquette d'origine (`Tripoli Cloud.dc.html`) incluait des éléments
sans fonctionnalité réelle possible dans cette version : 2FA, clé de
récupération, accès partagés, albums photo, dossiers, "4 appareils
sauvegardés", chiffres marketing sur la page de connexion, chiffrement
AES-256 côté client. Retirés plutôt que simulés - voir les commentaires
dans `src/api/*.ts` pour le détail de chaque décision.
## Développement
```bash
npm install
npm run dev # nécessite tripoli-api accessible sur /api (proxy Vite à ajouter si besoin en local)
npm run build # build de production, servi en statique par Caddy
```