8662e9e584
**Motivations:** - Anchor API requests were being aborted with 'This operation was aborted' error - API anchorage had performance issues causing long response times (30-60s) - Mutex could block indefinitely if a previous request crashed or timed out **Root causes:** - No timeout on mutex acquisition, causing indefinite blocking - Sequential RPC calls (8+ getNewAddress calls) instead of parallel - Expensive fee calculation making N RPC calls (one per input) instead of using known UTXO amounts - RPC timeout too short (30s) for slow Bitcoin node operations - No guarantee of mutex release in error cases **Correctifs:** - Added 180s timeout on mutex acquisition with Promise.race() to prevent indefinite blocking - Parallelized getNewAddress() calls with Promise.all() (9 sequential calls → 1 parallel call) - Optimized fee calculation to use known UTXO amounts instead of getRawTransaction() per input (saves N RPC calls, up to 20+) - Increased RPC timeout from 30s to 120s in .env.example - Added finally block to guarantee mutex release in all cases (success, error, timeout) - Added timeout and explicit error handling in api-filigrane callAnchorAPI() with AbortController (120s timeout) **Evolutions:** - Performance improvement: execution time reduced from ~30-60s to ~10-20s - RPC calls reduction: from ~15-35 calls to ~8-12 calls per anchor transaction - Better resilience: mutex cannot block indefinitely anymore - Improved error messages with explicit timeout/abort information **Pages affectées:** - api-anchorage/src/bitcoin-rpc.js: mutex timeout, parallel address generation, optimized fee calculation, finally block - api-anchorage/.env.example: increased RPC timeout to 120s - api-filigrane/src/routes/watermark.js: timeout and error handling for anchor API calls - fixKnowledge/api-filigrane-anchor-request-aborted.md: documentation of issues and fixes
84 lines
2.6 KiB
Markdown
84 lines
2.6 KiB
Markdown
# UserWallet – Validation stricte CNIL
|
||
|
||
**Author:** Équipe 4NK
|
||
**Date:** 2026-01-28
|
||
|
||
## Objectif
|
||
|
||
Implémenter la validation stricte CNIL pour les contrats et champs, permettant de transformer les warnings en erreurs selon la politique métier.
|
||
|
||
## Motivations
|
||
|
||
- Conformité CNIL stricte selon la politique métier
|
||
- Possibilité d'activer/désactiver la validation stricte
|
||
- Bloquer l'utilisation des contrats/champs non conformes CNIL en mode strict
|
||
|
||
## Modifications
|
||
|
||
### `src/utils/cnilValidation.ts`
|
||
|
||
- Ajout de `CNILValidationPolicy` pour configurer la validation
|
||
- Ajout de `DEFAULT_CNIL_POLICY` (mode non strict par défaut)
|
||
- Ajout de `STRICT_CNIL_POLICY` (mode strict avec tous les champs requis)
|
||
- Extension de `validateCNILFields()` pour accepter une politique
|
||
- Extension de `validateContractCNIL()` pour accepter une politique
|
||
- Extension de `validateChampCNIL()` pour accepter une politique
|
||
- Ajout de `getCNILPolicy()` pour récupérer la politique depuis le localStorage
|
||
- Ajout de `setCNILPolicy()` pour stocker la politique
|
||
|
||
### `src/services/graphResolver.ts`
|
||
|
||
- Mise à jour de `addContrat()` pour utiliser `getCNILPolicy()`
|
||
- Mise à jour de `addChamp()` pour utiliser `getCNILPolicy()`
|
||
- Rejet des contrats/champs non conformes en mode strict (suppression du cache)
|
||
|
||
## Utilisation
|
||
|
||
### Mode par défaut (non strict)
|
||
|
||
```typescript
|
||
import { validateContractCNIL, DEFAULT_CNIL_POLICY } from './utils/cnilValidation';
|
||
|
||
const validation = validateContractCNIL(contrat, DEFAULT_CNIL_POLICY);
|
||
// Génère des warnings mais n'échoue pas
|
||
```
|
||
|
||
### Mode strict
|
||
|
||
```typescript
|
||
import { validateContractCNIL, STRICT_CNIL_POLICY } from './utils/cnilValidation';
|
||
|
||
const validation = validateContractCNIL(contrat, STRICT_CNIL_POLICY);
|
||
// Génère des erreurs si les champs CNIL sont manquants
|
||
if (!validation.valid) {
|
||
// Contrat rejeté
|
||
}
|
||
```
|
||
|
||
### Configuration personnalisée
|
||
|
||
```typescript
|
||
import { setCNILPolicy, getCNILPolicy } from './utils/cnilValidation';
|
||
|
||
// Activer le mode strict
|
||
setCNILPolicy(STRICT_CNIL_POLICY);
|
||
|
||
// Récupérer la politique actuelle
|
||
const policy = getCNILPolicy();
|
||
```
|
||
|
||
## Politique métier
|
||
|
||
La politique CNIL peut être configurée via :
|
||
- `strict`: Mode strict (warnings → errors)
|
||
- `requireRaisonsUsageTiers`: Require `raisons_usage_tiers`
|
||
- `requireRaisonsPartageTiers`: Require `raisons_partage_tiers`
|
||
- `requireConditionsConservation`: Require `conditions_conservation`
|
||
|
||
En mode strict, les contrats/champs non conformes sont rejetés et retirés du cache du graphe.
|
||
|
||
## Références
|
||
|
||
- `features/userwallet-champs-obligatoires-cnil.md`
|
||
- `userwallet/docs/specs-champs-obligatoires-cnil.md`
|