Phase 3 : tripoli-api (auth, fichiers, PostgreSQL)
- axum + sqlx (requêtes runtime, pas les macros query! à vérification
compile-time - évite d'exiger une base joignable à chaque build).
- Auth par session opaque côté serveur (cookie HttpOnly/Secure/SameSite,
pas de JWT - révocation = suppression de ligne). Mots de passe
Argon2.
- Fichiers : upload multipart streamé chunk par chunk vers le disque
(jamais accumulé en mémoire - condition réelle d'une progression
d'upload non simulée), download streamé, blobs nommés par UUID
(le nom d'origine ne vit qu'en métadonnée).
- Stockage disque pour cette v1 (pas Object Storage - pas de bénéfice
réel pour un unique VPS avec 55 Go libres, ajouté sans complexité
inutile).
- PostgreSQL dans un conteneur Docker dédié, séparé de celui
d'iot-alarm-system (pas de couplage entre projets sans rapport).
- Déployé en prod sous systemd (même utilisateur système que
tripoli-edge), branché sur son upstream par défaut. Vérifié
bout-en-bout via https://tripoli.cloud/api/... : inscription,
connexion, upload, download, suppression, et les cas d'erreur
(401 sans session, 409 email déjà pris, 401 mauvais mot de passe,
404 double suppression).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-16 22:43:02 +02:00
|
|
|
[package]
|
|
|
|
|
name = "tripoli-api"
|
|
|
|
|
version = "0.1.0"
|
|
|
|
|
edition = "2021"
|
|
|
|
|
|
|
|
|
|
[dependencies]
|
|
|
|
|
tokio = { version = "1", features = ["rt-multi-thread", "macros", "fs", "signal", "io-util"] }
|
|
|
|
|
axum = { version = "0.8", features = ["multipart"] }
|
|
|
|
|
axum-extra = { version = "0.10", features = ["cookie"] }
|
|
|
|
|
tower-http = { version = "0.6", features = ["trace"] }
|
|
|
|
|
sqlx = { version = "0.8", features = ["runtime-tokio-rustls", "postgres", "uuid", "chrono", "migrate"] }
|
|
|
|
|
serde = { version = "1", features = ["derive"] }
|
|
|
|
|
serde_json = "1"
|
|
|
|
|
uuid = { version = "1", features = ["v4", "serde"] }
|
|
|
|
|
chrono = { version = "0.4", features = ["serde"] }
|
|
|
|
|
argon2 = "0.5"
|
|
|
|
|
password-hash = "0.5"
|
|
|
|
|
rand_core = { version = "0.6", features = ["std"] }
|
|
|
|
|
tracing = "0.1"
|
|
|
|
|
tracing-subscriber = { version = "0.3", features = ["env-filter", "json"] }
|
|
|
|
|
futures-util = "0.3"
|
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
|
|
|
nix = { version = "0.31", features = ["fs"] }
|
Phase 3 : tripoli-api (auth, fichiers, PostgreSQL)
- axum + sqlx (requêtes runtime, pas les macros query! à vérification
compile-time - évite d'exiger une base joignable à chaque build).
- Auth par session opaque côté serveur (cookie HttpOnly/Secure/SameSite,
pas de JWT - révocation = suppression de ligne). Mots de passe
Argon2.
- Fichiers : upload multipart streamé chunk par chunk vers le disque
(jamais accumulé en mémoire - condition réelle d'une progression
d'upload non simulée), download streamé, blobs nommés par UUID
(le nom d'origine ne vit qu'en métadonnée).
- Stockage disque pour cette v1 (pas Object Storage - pas de bénéfice
réel pour un unique VPS avec 55 Go libres, ajouté sans complexité
inutile).
- PostgreSQL dans un conteneur Docker dédié, séparé de celui
d'iot-alarm-system (pas de couplage entre projets sans rapport).
- Déployé en prod sous systemd (même utilisateur système que
tripoli-edge), branché sur son upstream par défaut. Vérifié
bout-en-bout via https://tripoli.cloud/api/... : inscription,
connexion, upload, download, suppression, et les cas d'erreur
(401 sans session, 409 email déjà pris, 401 mauvais mot de passe,
404 double suppression).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-16 22:43:02 +02:00
|
|
|
time = "0.3"
|
|
|
|
|
tokio-util = { version = "0.7", features = ["io"] }
|
|
|
|
|
mime_guess = "2"
|