Questa sarebbe una buona risposta per me, tranne il fatto che non riesco a far funzionare l’autenticazione basata sugli header, quindi sto tentando di farlo con i form e sto anche riscontrando problemi con il CSRF. Qualche soluzione? Sto cercando di creare un nuovo argomento tramite l’API.
Avremo bisogno di ulteriori informazioni per poter aiutarvi. Potete condividere un frammento di codice che mostri come state cercando di utilizzare l’autenticazione basata sulle intestazioni?
Il problema che ho riscontrato deriva principalmente dal fatto che, ogni volta che provo a effettuare una chiamata con autenticazione basata sugli header, gli header accettati sono sempre “User-Api-Key” e “User-Client-Id” invece di “Api-Key” e “Api-Username”, causando errori CORS. Non credo di aver bisogno di chiavi basate sull’utente. Sto solo cercando di eseguire una semplice richiesta autenticata per creare un nuovo argomento. Se provo a utilizzare “User-Api-Key”, ricevo errori 403.
Ecco un esempio di codice (Angular TypeScript), ma dovrebbe essere simile ad altre configurazioni:
createNewTopic(postBody: any) {
let url = "myserver.com/posts.json";
let CATEGORY_ARTICLES = 6;
let topicContent = `
<p>Alcuni contenuti
</p>
<p>Ha funzionato?</p>
`;
let post = {
"title": "Tdk Test 1",
"raw": topicContent,
"category": CATEGORY_ARTICLES,
"target_usernames": "tdekoekkoek",
"archetype": "",
"created_at": new Date()
}
let headers = new HttpHeaders()
.set("Accept", "application/json")
.set("User-Api-Key", DISCOURSE_API_KEY)
.set("User-Key", "system")
.set("Content-Type", "application/x-www-form-urlencoded")
let options = {headers: headers};
return this.http.post(url, post, options);
}
user-api-key e user-client-id sono un metodo di autenticazione completamente diverso. Le chiavi API normali non funzionano con quegli header. Cosa succede quando usi i nomi degli header corretti? (api-key e api-username)
Ricevo un errore CORS perché il server si aspetta l’header User-Api-Key. Esamino gli header attesi nella risposta OPTIONS e questo è ciò che viene indicato. C’è un argomento simile altrove in questo forum in cui un utente stava riscontrando questo problema chiamando da un’app JavaScript.
Ah, quindi stai cercando di inviare questa richiesta da un’applicazione JavaScript lato client? Questo non è consentito per diversi motivi. Ad esempio, se includi una chiave API di amministratore nel codice sorgente della tua app JavaScript, qualsiasi utente potrebbe ottenere pieno accesso amministrativo al tuo forum. Ecco un argomento precedente sull’argomento.
Sì, è proprio quello che sto cercando di fare. Dovrebbe essere documentato in modo più chiaro. Questa è stata la mia strategia da quando ho iniziato a utilizzare Discourse. Apprezzo il tuo aiuto. Sto lottando con questo problema da giorni e ho letto la documentazione. Dovrò ripensare all’intero approccio, dato che sto attualmente costruendo un’applicazione serverless, anche se ho accesso a un server Node.js.
Questa non è una restrizione specifica di Discourse: in generale, è una cattiva idea includere le credenziali di amministratore nel codice sorgente di un sito web.
Se puoi effettuare la chiamata all’API di Discourse dal tuo server Node.js, questa sarebbe probabilmente la soluzione migliore. Se la tua applicazione deve essere esclusivamente lato client, allora richiedere chiavi API specifiche per l’utente è un’opzione, anche se la loro configurazione è molto più complessa: User API keys specification
Francamente, l’accesso alle API da applicazioni client con CORS abilitato è estremamente comune e standard. Non riesco a credere che non esista un modo più sicuro per farlo. Un’intera industria ruota attorno alle API ospitate a cui si accede da diversi domini. Per quanto riguarda l’accesso con l’API utente, ho visto come crearle, ma non sono chiaro su quali siano le credenziali effettive. Ricevo sempre un errore 403
Penso di trovarmi in una situazione simile.
Un po’ di contesto sull’uso:
Utilizzo Discourse come backend e costruisco il frontend in VueJS. Intendo utilizzare esclusivamente la REST API. Per ogni utente della nostra piattaforma ho creato una chiave API utente e utilizzo entrambe le intestazioni (Api-Key & Api-Username) per l’autenticazione.
Ogni utente si autentica in modo sicuro con i nostri server e riceve quindi il proprio token Discourse per l’autenticazione. Successivamente, vogliamo utilizzare questo token (nel frontend VueJS) per inviare richieste API (pubblicare argomenti, post, modificare, ecc.).
Nulla è hard-coded; tutti i token vengono ricevuti dopo un’autenticazione corretta.
Il problema:
Sto ricevendo un messaggio di errore CORS, anche se l’ho abilitato in app.yml e configurato nella sezione Sicurezza delle Impostazioni di Amministratore.
L’errore: Il campo dell'intestazione della richiesta api-key non è consentito da Access-Control-Allow-Headers
Sto riscontrando l’errore CORS per lo stesso motivo? Perché le richieste CORS vengono bloccate quando si utilizzano le intestazioni “Api-Key” e “Api-Username”? Devo aver frainteso il loro caso d’uso.
EDIT:
Ho una teoria sul mio fraintendimento. Quando creo una chiave API utente dall’endpoint “Generate an api_key for a user” della REST API, quella chiave ha privilegi amministrativi? Non è semplicemente una chiave utente per pubblicare e commentare? Se è così, allora comprendo la restrizione.
Correggetemi se necessario.
@david Discourse non potrebbe semplicemente far firmare al server un segreto di sessione con un HMAC, e questo segreto di sessione a sua volta potrebbe essere usato per firmare elementi nella data sessione? Se venisse rubato, allora presumibilmente nemmeno il cookie di sessione o il nonce CSRF lo sarebbero. È un po’ come una catena di certificati: non devi mettere la chiave root nel browser.
Questi sono solo per l’API di amministrazione. Il modo in cui l’ho capito è che per i client JavaScript è necessario, come menzionato sopra, controllare User API keys specification .