Blomios
481a7e2498
Enregistre l'état du registre de tickets : #74 et #68 passent en closed après la validation live de l'intégration web, #75 (ce fix) entre en QA et #76 ouvre la dette de casse du code d'appairage côté serveur. État runtime uniquement : aucun code de feature n'est touché. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.6 KiB
id, number, title, status, priority, sprint, links, agentRefs, createdBy, updatedBy, createdAt, updatedAt, version
| id | number | title | status | priority | sprint | links | agentRefs | createdBy | updatedBy | createdAt | updatedAt | version | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| c91f547f-96f0-4c9c-9fde-dbe7d2772dbc | 76 | Appairage : la comparaison du code est sensible à la casse côté serveur | open | low | null |
|
|
|
1784277540034 | 1784277540034 | 1 |
Constat
crates/web-server/src/lib.rs:1612 compare le code d'appairage reçu au code attendu par égalité stricte :
if request.code != state.pairing_code() { … }
Or new_pairing_code() (ligne 2220) génère le code en majuscules. Un client qui envoie 3f7a9c21 au lieu de 3F7A9C21 est donc rejeté.
Pourquoi c'est une dette et pas un bug bloquant
Le fix #75 rend l'écran web tolérant en normalisant la saisie en majuscules avant POST /api/pair. La tolérance vit donc côté client : tout autre client de l'API (curl, un futur client mobile natif, un test manuel) échouera encore sur une saisie minuscule, avec un message d'erreur qui n'explique pas pourquoi.
Attendu
La comparaison serveur normalise la casse (et les espaces) avant égalité. La normalisation côté UI de #75 devient alors redondante mais inoffensive — pas besoin de la retirer.
Vigilance
La comparaison doit rester en temps constant si elle l'est aujourd'hui : normaliser ne doit pas introduire de court-circuit exploitable en timing. À vérifier lors de l'implémentation.
Périmètre
Backend pur, crates/web-server.