Sto riscontrando un problema con l’integrazione di Discourse nel nostro sito intranet.
La documentazione API indica che la richiesta a Discourse richiede le intestazioni “API-Key” e “Api-Username” per l’autenticazione e l’accesso al feed. Tuttavia, il controllo pre-volo (pre-flight) indica che i valori consentiti sono “User-API-Key” e “User-Api-Client-Id”.
Quando la chiamata non viene effettuata tramite browser, tutto funziona come previsto. Ma quando la richiamo tramite browser, il server afferma che sono necessarie le intestazioni “User-API-Key” e “User-Api-Client-Id”.
Ho verificato che la connessione di base funzioni con Postman, che si comporta in linea con la documentazione di Discourse.
Se inviamo le intestazioni indicate nella documentazione, il browser blocca la richiesta a causa del controllo pre-volo e restituisce un errore CORS relativo a Access-Control-Allow-Headers.
Se inviamo le intestazioni che il server accetta, otteniamo un errore “non autorizzato” perché l’applicazione si aspetta valori con nomi diversi.
Ho provato ad aggiungere le intestazioni alla configurazione Docker, ma sembra non avere effetto. CORS è abilitato e l’origine è impostata su “*” nella configurazione.
Abbiamo due diversi sistemi di autenticazione API, che possono creare confusione.
Questi sono destinati all’“API di amministrazione”, descritta su docs.discourse.org. Non sono progettati per essere utilizzati da client JavaScript.
Questi provengono dalla specifica “User API”, che può essere utilizzata da un client JavaScript (e quindi supporta CORS). Maggiori dettagli sono disponibili qui: User API keys specification
@david Sto utilizzando SSO e desidero disconnettere l’utente da Discourse quando si disconnette dall’app. Attualmente sto usando l’“admin API” per recuperare l’ID utente tramite /users/by-external/${id}.json, ma ricevo errori CORS. Non vorrei abilitare la “user API” per ogni utente solo per questo processo di disconnessione: cosa mi suggerisci?
Chi sta eseguendo la richiesta all’API di amministrazione? JavaScript nella tua applicazione client?
Non dovresti includere un’API di amministrazione in un client JavaScript, poiché significherebbe che chiunque utilizzi il client potrebbe ottenere l’accesso amministrativo al tuo sito.
Sì, nel mio’app si tratta di JavaScript. Capisco. Quindi qual è l’alternativa? Posso aggiungere un’API ‘utente’ per un singolo utente e utilizzarla per effettuare la chiamata per tutti gli utenti?
Se utilizzi la User API, dovresti farlo per ogni utente. Non dovresti condividere le chiavi.
Tuttavia, la soluzione più comune in questo caso è gestirla lato server della tua applicazione. Il tuo server può inviare una richiesta utilizzando le chiavi API di amministratore senza problemi di CORS e con minori preoccupazioni di sicurezza (purché sia implementato in modo sicuro).
Ciao @david, ho provato a implementare una soluzione lato backend, ma quando chiamo https://example.com/users/by-external/{EXTERNAL_USER_ID}.json?api_key={DISCOURSE_API_KEY}&api_username=system, la risposta che ricevo è l’HTML della pagina di accesso (immagino che venga reindirizzato lì). Ho abilitato l’impostazione “accesso richiesto” e quando la disabilito, ottengo la corretta risposta JSON. Voglio mantenere attiva quell’impostazione: hai qualche idea su cosa stia succedendo?
