Après avoir discuté avec mon collègue @owengot, voici une description plus détaillée du problème.
Il existe une application web basée sur Vue.js qui ne dispose pas de son propre composant côté serveur actif. Il s’agit plutôt d’une application web autonome qui utilise l’API Discourse, de sorte que, d’une certaine manière, Discourse joue le rôle du serveur. Les cas d’usage incluent des sondages ou formulaires autonomes, où le contenu est publié dans des sujets Discourse sous le compte de l’utilisateur. Pouvoir créer un tel logiciel sans composants personnalisés côté serveur semblait être une bonne architecture pour ces cas d’usage ; idéalement, nous voudrions donc éviter de faire quoi que ce soit « côté serveur ».
Maintenant, l’obtention d’une clé API utilisateur fonctionne comme prévu, mais @owengot a découvert que l’étape de génération d’une clé privée en JavaScript prend beaucoup de temps (jusqu’à 10 secondes, c’est simplement inefficace en JavaScript …). Ensuite, il a découvert l’astuce consistant à utiliser la même clé privée pour plusieurs utilisateurs, il l’a donc stockée dans un fichier sur l’hébergeur web qui sert également les autres fichiers statiques de l’application web (JS, CSS, etc.). Cela rend le processus rapide … mais cette clé privée est maintenant (1) partagée et (2) stockée en clair, avec une URL accessible publiquement. Cela semble, euh, effrayant 
J’ai donc dit que nous devions demander à l’équipe Discourse quelles sont les implications de sécurité de cette astuce. Je vois deux alternatives de base :
-
Si cette clé privée n’est « que » utilisée pour le chiffrement des charges utiles, nous pourrions nous en accommoder, car la communication est également chiffrée via SSL / HTTPS.
-
Mais si connaître cette clé privée permet de calculer la clé API utilisateur résultante, utilisée ensuite pour publier sous le compte Discourse de quelqu’un, cela rendrait bien sûr cette astuce inacceptable.