Después de hablar con mi colega @owengot, aquí tienes una descripción más detallada del problema.
Existe una aplicación web basada en Vue.js que no tiene su propio componente activo en el lado del servidor. Más bien, es una aplicación web independiente que utiliza la API de Discourse, de modo que, en cierto sentido, Discourse actúa como el servidor. Los casos de uso incluyen encuestas o formularios independientes, donde el contenido se publica en temas de Discourse bajo la cuenta del usuario. Poder crear este tipo de software sin componentes personalizados en el lado del servidor parecía una arquitectura adecuada para estos casos, por lo que, idealmente, querríamos evitar hacer cualquier cosa “en el lado del servidor”.
Ahora bien, obtener una clave de API de usuario funciona como se espera, pero @owengot descubrió que el paso de generar una clave privada en JavaScript tarda mucho tiempo (hasta 10 segundos; es simplemente ineficiente en JavaScript…). Luego, encontró un truco: la misma clave privada puede usarse para varios usuarios, por lo que la almacenó en un archivo en el servidor web que también sirve los demás archivos estáticos de la aplicación web (JS, CSS, etc.). Esto lo hace rápido… pero ahora esa clave privada es (1) compartida y (2) está almacenada de forma abierta, con una URL accesible públicamente. Eso parece, hum, aterrador 
Así que dije que debemos consultar al equipo de Discourse sobre las implicaciones de seguridad de este truco. Veo dos alternativas básicas:
-
Si esa clave privada se usa “únicamente” para cifrar la carga útil, podríamos aceptarlo, ya que también tenemos la comunicación cifrada mediante SSL/HTTPS.
-
Pero si conocer esa clave privada permite de alguna manera calcular la clave de API de usuario resultante que luego se usa para publicar bajo la cuenta de alguien en Discourse, por supuesto, haría que este truco fuera inaceptable.