Stiamo utilizzando Discourse come strumento di collaborazione e disponiamo di un’altra applicazione per la ricerca dei documenti. Vorremmo integrare i commenti relativi ai documenti in Discourse. Entrambe le applicazioni utilizzano un provider SSO/OAuth esterno all’interno della nostra infrastruttura.
Stiamo utilizzando la User API Key per collegare le due applicazioni, consentendo loro di comunicare. Funziona correttamente, ma dobbiamo cliccare sul modulo “Authorize application access” che vorremmo evitare, dato che ci troviamo in un ambiente attendibile protetto da OAuth.
Esiste un modo per evitare questo passaggio di “autorizzazione” o aggirarlo, andando direttamente alla creazione della User API Key, in modo che questa pagina non venga visualizzata e gli utenti non debbano eseguire questo passaggio aggiuntivo? È possibile fornire un parametro nella richiesta per bypassare questo passaggio?
Abbiamo provato a chiamare prima UserApiKeysController.create (invece di UserApiKeysController.new), ma abbiamo ricevuto un errore CSRF. Abbiamo quindi provato a saltare il controllo del token nel seguente modo:
class UserApiKeysController < ApplicationController
skip_before_action :verify_authenticity_token
Posso affermare con certezza che questa non è la strada corretta da seguire. Stai già utilizzando un plugin o interagisci solo tramite HTTP?
Se stai utilizzando un plugin, nella maggior parte dei casi non dovresti interagire con le istanze di app/controllers/.
Se stai interagendo tramite HTTP e stai utilizzando una comunicazione server-to-server, sarebbe meglio utilizzare una chiave API creata da un amministratore.
L’API utente è destinata alla comunicazione client-to-server, dove non è possibile garantire l’integrità del codice sul lato client.
Sì, abbiamo intenzione di sviluppare un plugin per Discourse e la nostra applicazione JS interagirà esclusivamente tramite richieste HTTP.
Vorremmo evitare di dover implementare una comunicazione server-to-server (ad esempio tramite l’uso della chiave API di amministrazione) per ridurre l’accoppiamento tra i componenti.
Capisco che, idealmente, non dovremmo modificare i controller di Discourse; allo stesso tempo, esistono molti metodi che sembrano progettati per essere sovrascritti (pattern del metodo template e altri punti di estensione), e da quanto abbiamo visto finora, molti plugin agiscono in questo modo.
Quale sarebbe quindi la strada corretta da seguire?
Se stai sviluppando un plugin, dovresti creare nuove rotte in un controller montato sul plugin che eseguono direttamente le attività necessarie. Queste rotte possono condividere un before_action che imposta gli header di risposta Access-Control-Allow-{Origin, Headers, Credentials} (riecheggia l’header di richiesta Origin se è presente nell’elenco dei domini su cui la tua applicazione dovrebbe essere eseguita).
In questo modo, il tuo codice JS può semplicemente invocare fetch(..., { credentials: "include", ...}) senza alcuna chiave API.
Grazie @riking, funziona bene quando abbiamo una sessione aperta su Discourse nel browser.
Possiamo avviare una nuova sessione manualmente chiamando semplicemente http://discourse_site/login, dato che abbiamo impostato SiteSetting.enable_local_logins = false e utilizziamo un solo meccanismo di autenticazione basato su OAuth. Il browser segue i reindirizzamenti verso il nostro provider OAuth e poi torna a Discourse. Questo è esattamente ciò che avveniva internamente quando si chiamava /user-api-key/new.
Come potremmo avviare programmaticamente una nuova sessione di Discourse dall’app se non ne esiste una?
forse