Revue de code de RyzenDesk : une vraie sécurité et une porte de chat laissée ouverte
Ticketing, SLA, Kanban, wiki, analytics, automation, IA, e-mail, Telegram, RBAC et Git chiffré. Build, type-check et audit passent ; le chat anonyme doit être corrigé.
DEEP PROJECT REVIEW · SOURCE + REPOSITORY VISUALS
RyzenDesk est le plus gros produit de cette série de revues, et l’un de ceux dont les promesses de sécurité résistent en grande partie au contact du code. Le serveur Express enregistre 96 gestionnaires de routes. Le client React couvre files de tickets, réponses en fil, Kanban, wiki, analytique, installation, politiques d’administration, fournisseurs d’IA, portail client et navigation mobile. Les points soignés sont réels : mots de passe scrypt, sessions signées HMAC, RBAC côté serveur, jetons clients hachés, secrets chiffrés, contrôles SSRF stricts sur les webhooks, validation d’origine, limites de débit et secrets de production qui font échouer le démarrage s’ils manquent. Un chemin public de chat en direct casse le schéma.
Ingénierie solide
- RBAC serveur à cinq niveaux
- scrypt, sessions HttpOnly et tokens hashés
- Contrôles SSRF et webhooks HMAC
- build, type-check et audit réussis
Limites importantes
- Aucune démo live vérifiée
- chat start renvoie un thread existant selon un e-mail déclaré
- Thread ID seul secret pour lire, écrire et fermer
- Gros bundle et aucun test automatisé
Comment c’est assemblé
Une SPA React/Vite appelle Express. Une base JSON typée garde les données ; les sessions restent locales. Les snapshots Git sont chiffrés AES-256-GCM. SMTP, Telegram, e-mail et webhooks relient les services. Un JSON et l’état local limitent la montée en charge.
La profondeur des fonctions
96 routes couvrent tickets, SLA, bulk, presence, temps, CSAT, merge, export, Kanban, wiki, analytics, RBAC, SMTP, webhooks, audit, install, règles, chat et fournisseurs IA.
La revue de sécurité, et la seule fissure
Les routes cœur sont bien protégées : secrets fail-closed, scope client, tokens hashés, blocage SSRF et HMAC. Mais chat start cherche un thread selon l’e-mail fourni et le renvoie. L’ID devient la capability pour lire, écrire et fermer. Il faut un secret séparé hashé, aucun recovery par e-mail et une vérification par opération.
Une URL à capacité n’est sûre que si personne ne peut en retrouver la capacité à partir d’une simple déclaration d’identité publique.
| Contrôles de sécurité | Failles et limites |
|---|---|
| scrypt, HMAC sessions, RBAC | Process-local sessions and limits |
| Hashed customer tokens | Anonymous chat email recovery |
| SSRF-resistant signed webhooks | No automated auth regression suite |
| Encrypted Git snapshot | Single JSON write model |
Ce que montrent les contrôles qualité
Lint/type-check, build et audit sans advisory passent. CI lance install, lint, build. Le bundle principal fait 989,57 kB avant gzip. Aucun test trouvé.
Son allure et son texte
Dix screenshots montrent une console slate/indigo cohérente, queues, SLA et thread lisible. La richesse exige de la progressive disclosure. Pas de démo live.
Verdict
Bonne base self-hosted. Corrigez le chat d’abord ; pour l’échelle : sessions/rate limits partagés, DB transactionnelle, tests d’autorisation et code splitting.
FAQ
Qu’est-ce que RyzenDesk ?
Un helpdesk MIT auto-hébergé avec ticketing, SLA, Kanban, wiki, analytics, IA, RBAC et persistance Git chiffrée.
Existe-t-il une démo ?
Non ; dix screenshots et des instructions Docker/local sont fournis.
Prêt pour la production ?
La sécurité cœur est forte, mais les capabilities du chat et les tests doivent être corrigés avant exposition publique.
Source repository
Reviewed source at commit 4d4aa64 · No separate live demo listed · build, type-check and audit reproduced 2026-09-21