46bf9676a0
**Motivations:** - Ensure all application directories have systemd services enabled at boot - Complete service installation for api-relay, filigrane-api, and clamav-api - Fix dependencies and import issues preventing clamav-api from starting **Root causes:** - Three services (api-relay, filigrane-api, clamav-api) had service files but were not installed in systemd - api-clamav had incorrect node-clamav version (0.12.1) that doesn't exist - api-clamav dependencies were not installed (node_modules missing) - ES module import syntax incompatible with CommonJS node-clamav package **Correctifs:** - Installed api-relay.service, filigrane-api.service, and clamav-api.service in /etc/systemd/system/ - Enabled all three services for automatic startup at boot - Updated api-clamav/package.json: changed node-clamav version from ^0.12.1 to ^1.0.11 - Installed npm dependencies for api-clamav - Fixed ES module import in api-clamav/src/routes/scan.js to use CommonJS-compatible syntax **Evolutions:** - All 7 application services now have systemd services enabled at boot - Complete service coverage: anchorage-api, faucet-api, signet-dashboard, userwallet, api-relay, filigrane-api, clamav-api - All services verified active and listening on their respective ports **Pages affectées:** - api-clamav/package.json - api-clamav/src/routes/scan.js - api-clamav/node_modules/ (new) - api-clamav/package-lock.json (new) - /etc/systemd/system/api-relay.service (new) - /etc/systemd/system/filigrane-api.service (new) - /etc/systemd/system/clamav-api.service (new)
110 lines
3.1 KiB
Markdown
110 lines
3.1 KiB
Markdown
# UserWallet API Relay
|
||
|
||
Serveur de relais pour le système de login décentralisé UserWallet.
|
||
|
||
## Fonctionnalités
|
||
|
||
- Stockage des messages chiffrés (sans signatures ni clés)
|
||
- Stockage séparé des signatures
|
||
- Stockage séparé des clés de déchiffrement
|
||
- Relais entre pairs (inter-relay)
|
||
- Déduplication par hash
|
||
- Endpoints REST pour GET/POST
|
||
- Rate limiting (par IP)
|
||
- CORS configurable
|
||
- Logging structuré (Pino)
|
||
- Métriques Prometheus (`GET /metrics`)
|
||
- Compression des réponses (gzip)
|
||
- Indexation par `service_uuid` pour GET /messages
|
||
- Bloom filter des hash vus (`GET /bloom`)
|
||
|
||
## Installation
|
||
|
||
```bash
|
||
npm install
|
||
```
|
||
|
||
## Configuration
|
||
|
||
Variables d'environnement :
|
||
|
||
- `PORT` : Port d'écoute (défaut: 3019)
|
||
- `HOST` : Adresse d'écoute (défaut: 0.0.0.0)
|
||
- `STORAGE_PATH` : Chemin de stockage (défaut: ./data)
|
||
- `PEER_RELAYS` : Liste de relais pairs séparés par virgule (ex: http://relay1:3019,http://relay2:3019)
|
||
- `SAVE_INTERVAL_SECONDS` : Sauvegarde périodique (défaut: 300, 0 = désactivé)
|
||
- `BODY_LIMIT` : Taille max body JSON (défaut: 1mb)
|
||
- `REQUEST_TIMEOUT_MS` : Timeout requête HTTP (défaut: 30000)
|
||
- `RATE_LIMIT_WINDOW_MS` : Fenêtre rate limit (défaut: 60000)
|
||
- `RATE_LIMIT_MAX` : Requêtes max par fenêtre et par IP (défaut: 200)
|
||
- `CORS_ORIGINS` : Origines CORS autorisées, séparées par virgule (vide = toutes)
|
||
- `LOG_LEVEL` : Niveau log Pino (défaut: info, debug en dev)
|
||
- `NODE_ENV` : production | autre
|
||
|
||
## Développement
|
||
|
||
```bash
|
||
npm run dev
|
||
```
|
||
|
||
## Build
|
||
|
||
```bash
|
||
npm run build
|
||
npm start
|
||
```
|
||
|
||
## Déploiement (systemd)
|
||
|
||
```bash
|
||
sudo cp api-relay.service /etc/systemd/system/
|
||
sudo systemctl daemon-reload
|
||
sudo systemctl enable api-relay
|
||
sudo systemctl start api-relay
|
||
```
|
||
|
||
`start.sh` build puis lance `node dist/index.js`.
|
||
|
||
## Endpoints
|
||
|
||
### Health
|
||
|
||
- `GET /health` - Vérification de santé
|
||
|
||
### Messages
|
||
|
||
- `GET /messages?start=<timestamp>&end=<timestamp>&service=<uuid>` - Récupérer les messages dans une fenêtre temporelle
|
||
- `POST /messages` - Publier un message chiffré
|
||
- `GET /messages/:hash` - Récupérer un message par hash
|
||
|
||
### Signatures
|
||
|
||
- `GET /signatures/:hash` - Récupérer les signatures pour un message
|
||
- `POST /signatures` - Publier une signature
|
||
|
||
### Clés
|
||
|
||
- `GET /keys/:hash` - Récupérer les clés de déchiffrement pour un message
|
||
- `POST /keys` - Publier une clé de déchiffrement
|
||
|
||
### Métriques
|
||
|
||
- `GET /metrics` - Métriques Prometheus (relay_storage_entries par kind)
|
||
|
||
### Bloom
|
||
|
||
- `GET /bloom` - Bloom filter (JSON) des hash vus. Les clients peuvent l’utiliser pour éviter de demander des messages déjà connus.
|
||
|
||
## Architecture
|
||
|
||
Le relais respecte la séparation stricte :
|
||
1. Messages publiés sans signatures ni clés
|
||
2. Signatures publiées séparément
|
||
3. Clés publiées séparément
|
||
|
||
La déduplication par hash évite de relayer deux fois le même message.
|
||
|
||
## Stockage
|
||
|
||
Stockage en mémoire avec persistance sur disque (`{STORAGE_PATH}/messages.json`). Sont persistés : messages, seenHashes, signatures, clés. Sauvegarde à l’arrêt (SIGINT/SIGTERM) et périodiquement si `SAVE_INTERVAL_SECONDS` > 0. En production, une base de données (SQLite, PostgreSQL, etc.) est recommandée.
|