Nous utilisons Discourse comme outil de collaboration et nous avons une autre application pour rechercher des documents. Nous souhaitons intégrer les commentaires sur les documents dans Discourse. Les deux applications utilisent un fournisseur SSO/OAuth externe au sein de notre infrastructure.
Nous utilisons la clé API utilisateur pour connecter les deux applications afin qu’elles puissent communiquer. Cela fonctionne bien, mais nous devons cliquer sur le formulaire « Autoriser l’accès à l’application », que nous aimerions éviter car nous sommes dans un environnement de confiance sécurisé par OAuth.
Existe-t-il un moyen d’éviter cette étape d’autorisation, ou de la contourner pour accéder directement à la création de la clé API utilisateur, afin que cette page ne s’affiche pas et que les utilisateurs n’aient pas à effectuer cette étape supplémentaire ? Y a-t-il un paramètre que nous pourrions fournir dans la requête pour contourner cette étape ?
Nous avons essayé d’appeler UserApiKeysController.create en premier (au lieu de UserApiKeysController.new), mais nous avons rencontré une erreur CSRF. Nous avons donc essayé de sauter la vérification du token comme ceci :
class UserApiKeysController < ApplicationController
skip_before_action :verify_authenticity_token
Je peux affirmer sans hésiter que ce n’est pas la bonne approche. Utilisez-vous déjà un plugin ou interagissez-vous uniquement via HTTP ?
Si vous utilisez un plugin, vous ne devriez généralement pas interagir avec les instances de app/controllers/.
Si vous interagissez via HTTP et que vous utilisez une communication serveur-à-serveur, il serait préférable d’utiliser une clé API créée par un administrateur.
L’API utilisateur est conçue pour la communication client-à-serveur, où il est impossible d’assurer l’intégrité du code côté client.
Oui, nous prévoyons de développer un plugin pour Discourse et notre application JS n’interagira que via des requêtes HTTP.
Nous souhaitons éviter de devoir mettre en place une communication serveur-à-serveur (par exemple en utilisant une clé API d’administration) afin de minimiser le couplage entre les composants.
Je comprends qu’idéalement, nous ne devrions pas modifier les contrôleurs de Discourse. En même temps, il existe de nombreuses méthodes qui semblent conçues pour être surchargées (modèle de méthode de template et autres points d’extension), et d’après ce que nous avons vu jusqu’à présent, de nombreux plugins agissent ainsi.
Si vous développez un plugin, vous devez créer de nouvelles routes dans un contrôleur monté sur le plugin qui exécutent directement les tâches nécessaires. Ces routes peuvent toutes partager un before_action qui définit les en-têtes de réponse Access-Control-Allow-{Origin, Headers, Credentials} (renvoyez l’en-tête de requête Origin s’il figure dans la liste des domaines sur lesquels votre application doit s’exécuter).
De cette façon, votre code JS peut simplement appeler fetch(..., { credentials: "include", ...}) sans aucune clé API.
Merci @riking, cela fonctionne bien lorsque nous avons une session ouverte sur Discourse dans le navigateur.
Nous pouvons démarrer une nouvelle session manuellement en appelant simplement http://discourse_site/login, car nous avons configuré SiteSetting.enable_local_logins = false et utilisons un seul mécanisme d’authentification avec OAuth. Le navigateur suit les redirections vers notre fournisseur OAuth, puis redirige vers Discourse. C’est exactement ce qui se passait en coulisses lors de l’appel à /user-api-key/new.
Comment pourrions-nous initier une nouvelle session Discourse de manière programmatique depuis l’application s’il n’y en a aucune ?
peut-être que