I find allowed_user_api_auth_redirects default of “discourse://auth_redirect” rather restrictive, especially because “discourse” does not appear to be a valid URI scheme.
Please explain the thinking behind this default. Thank you.
I am having this issue as well. If I initiate the API from a JS application, then automatically the allowed headers are: User-Api-Key, User-Api-Client-Id even though I do not need user API keys. All I want is a simple API key but I cannot get anything to work. If I try to pass Api-Key in the headers I get a CORS error since it expects User-Api-Key. But when I try to use User-Api-Key, I get 403 errors. I am stuck. I would think this is the base usage for using the APIs. I am not trying to do anything out of the ordinary. I am simply trying to create a new topic post.
2 Mi Piace
That is the custom URI scheme used by the DiscourseHub app for iOS and Android.
6 Mi Piace
I’ve got a question concerning the “read tokens” and “write tokens”. This comment here is from 2016, so this possibly had already been changed? Or are the defaults still only “read tokens”?
Background: I’m one of the coders behind a distributed social media system. We already do have connectors to non-federating systems. The idea is to write an addon for discourse as well. But when most likely most system won’t allow users to generate tokens that allow posting, we will try another way. We already do have a mail connector. Then we will simply use the mailing list function of Discourse and we will try to enhance the returned content and will post via SMTP.
You can do write tokens if you ask for the scope upfront
3 Mi Piace
Of course this is always possible. But I have the feeling that this is a support nightmare. Our software has got some hundred installations with (in total) more than 10k users. When they see that there is an addon that is connection to Discourse, many will surely like to use it. And since it most likely won’t work out of the box, this will generate questions and support work from our side. Additionally it will generate work for the admins of the several Discourse installations. And very likely not all will allow it - which will cause frustration.
So possibly at first I will focus on integrating the mailing list mode mails. Or is it possible to combine these two? Means: Reading of the posts via the API, but posting via SMTP?
Hi…I don’t know to generate public_key… should I use RSA generator to get public/private key?
If so I have done with some online RSA generators. but I am getting this error:
OpenSSL::PKey::RSAError (Neither PUB key nor PRIV key: nested asn1 error) /var/www/discourse/app/controllers/user_api_keys_controller.rb:189:in `initialize'
Also, I want to ask you guys if this suits my user case:
I have an app, and I want to basically authenticate user and get the username, is generating api key flow the simplest flow for me to validate user’s login in my app? If possible, I want avoid SSO because it seems more complicate.
Same boat here, although I am only trying to use User-Api-Key (not Api-Key) to create a topic post and am getting CSRF denial from the actionpack library.
Unless the discourse server has turned off CSRF checking, posting from a third-party desktop app seems hard. I’m not about to emulate a browser.
@sam What is your take on allowing User API Keys that only have the read scope attached, to be passed via URL params on GET requests?
Use case is allowing integrations like subscribing your Improved Bookmarks with Reminders in Google Calendar using User API keys.
5 Mi Piace
How about creating a specific new scope, with a third parameter to indicate “get param allowed”. That way, people can’t misuse it for other things (e.g. bypassing CORS and requesting the discourse API from another site).
SCOPES = {
read: [:get],
write: [:get, :post, :patch, :put, :delete],
message_bus: [[:post, 'message_bus']],
push: nil,
one_time_password: nil,
notifications: [[:post, 'message_bus'], [:get, 'notifications#index'], [:put, 'notifications#mark_read']],
session_info: [
[:get, 'session#current'],
[:get, 'users#topic_tracking_state'],
[:get, 'list#unread'],
[:get, 'list#new'],
[:get, 'list#latest']
],
+ calendar: [ [:get, 'users#bookmarks_cal', true ] ],
}
(Aside: why are we using nested arrays here…)
10 Mi Piace
I like that the API key would be flagged explicitly as “allowed in GET” at the user level.
As a whole the option could be open for any GETs. The rule I like is, when operating in this mode:
- User API key is 100% restricted to a single specific GET controller action
- User API key is flagged as allowed in GET query params.
This limits the impact of any leak here via a proxy cause the key will never be reused.
I guess {get: 'list#new'} , {get: 'list#latest'} would work as well.
7 Mi Piace
I’m super interested in get param only type user api keys. My question is, are you guys planning to allow people to generate these keys via UI?
Probably, maybe behind a site setting or with a plugin. We do plan to normalise the feature set a bit so admin api keys also support scopes.
4 Mi Piace
Hi…Are you able to resolve this issue? I have the same issue and not able to fix it. I tried passing different type of keys and nothing worked. Any help would be greatly appreciated.
Esistono librerie per questo? In caso contrario, un esempio di implementazione? Sto cercando di utilizzare PHP per identificare l’account Discourse di un utente in una sezione separata del sito web. Sembra un flusso OAuth modificato, ma sono un po’ confuso su come implementarlo.
In particolare, non sono sicuro di come gestire l’intera generazione delle chiavi pubblica/privata.
Esiste un modo per utilizzare semplicemente OAuth 2 con Discourse come provider OAuth?
2 Mi Piace
Sei riuscito a farlo usando la User-Api-Key? Sto ricevendo anch’io il messaggio ‘You are not permitted to view the requested resource’.
1 Mi Piace
Ho capito cosa ho fatto di sbagliato: il payload restituito non è la chiave API di UserAPI stessa, ma una stringa JSON cifrata, che deve essere decifrata con la chiave privata della coppia di chiavi pubblica/privata.
2 Mi Piace
AGGIORNAMENTO: Sono riuscito a far funzionare la maggior parte delle cose e fornirò una descrizione non appena avrò completato il tutto.
Come fa il client a ottenere la coppia di chiavi privata/pubblica e l’ID?
Potete fornire del codice per ottenere la chiave API dell’utente con un’app JavaScript? (Un’app JavaScript che cerca di permettere a un utente di effettuare chiamate API a un forum Discourse).
Sto ricevendo errori 403. Oppure un errore che dice: Spiacenti, non siamo in grado di emettere chiavi API per gli utenti; questa funzionalità potrebbe essere disabilitata dall'amministratore del sito (anche se nel mio sito è spuntata l’opzione: Consenti la generazione di chiavi API per gli utenti).
Penso che il problema possa essere legato a come generare la coppia di chiavi privata/pubblica (come si fa?) e poi a come gestire il reindirizzamento.
Qualsiasi codice è apprezzato.
Sono riuscito a farlo funzionare, dopo qualche tentativo ed errore.
Ecco i passaggi di base che seguo quando: ho un’app separata che ho codificato e voglio che gli utenti possano utilizzarla per effettuare chiamate API a un sito Discourse.
Per fare ciò, devo generare un token API per utente per effettuare chiamate per conto di ogni utente specifico (almeno in un ambiente Node.js/JavaScript).
Nota: per la parte JavaScript, ho trovato molto utile il codice fornito da @KengoTODA qui: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
Ecco i passaggi che ho seguito:
Primo: Generare una coppia di chiavi pubblica e privata.
Questo è qualcosa che la tua app deve generare: una chiave pubblica e una chiave privata. Il gist di GitHub fornisce un metodo per farlo.
Secondo: Avere un URL di reindirizzamento.
Questo è l’URL a cui Discourse reindirizzerà, fornendo il token API finale nel payload. Se hai un’app desktop (cioè senza URL del browser), l’URL di reindirizzamento si baserà su un protocollo personalizzato che hai configurato e che apre l’app quando l’URL di reindirizzamento viene inserito nel browser.
Nota che l’URL di reindirizzamento deve essere inserito nella whitelist nelle impostazioni del sito del sito Discourse di destinazione.
Il sito Discourse deve anche probabilmente avere attiva l’impostazione del sito “Consenti chiavi API utente”. Consulta il post originale su questo argomento per le “Impostazioni del sito”.
Terzo: Inviare la chiamata della richiesta API all’URL di richiesta di Discourse.
La tua app invierà quindi una chiamata a un URL che segue questo formato:
https://[il tuo sito Discourse di destinazione .com]/user-api-key-new"
aggiungendo come parametri:
- il nome della tua app
- il tuo “client_id” (sono riuscito a usare hostname(), da
const {hostname} = require('os')per un’app desktop, proprio come nel gist di GitHub citato sopra) - gli ambiti (questi sono gli ambiti che desideri che l’utente possa utilizzare tramite l’API, come “write”, “read”, ecc.)
- la tua chiave pubblica (dal passaggio 1 sopra)
- il tuo URL di reindirizzamento (dal passaggio 2 sopra)
- nonce (questo è un valore che puoi scegliere: ad esempio, usare semplicemente ‘1’ sembra funzionare)
Quarto: L’utente autorizza la tua app sulla pagina del sito Discourse aperta dall’URL di richiesta
Quando invii con successo l’URL di richiesta, si apre una pagina sul sito Discourse che informa l’utente che la tua app vuole accedere al sito.
Su quella pagina, c’è un pulsante per l’utente per consentire questa operazione. Quando l’utente clicca su questo pulsante, il sito Discourse reindirizza all’URL di reindirizzamento che hai fornito e allega come parametro ?payload=[LA CHIAVE API]. LA CHIAVE API qui è la chiave che devi decodificare nella tua app.
Quinto: La tua app riceve il valore dell’URL di reindirizzamento (con il valore del payload) e decodi la CHIAVE API
Sei quasi arrivato. La tua app deve analizzare l’URL di reindirizzamento a cui è andato Discourse e ottenere la Chiave API contenuta nel payload.
Una volta ottenuta quella Chiave API, devi fare due cose:
- Ottenere la chiave effettiva, non la versione codificata nell’URL: se stai ottenendo un parametro da un URL, spesso è codificato nell’URL (aggiungendo % qui e là, ecc.). Devi pulirlo. In JavaScript, ho trovato che
decodeURIComponentfunziona per questo. - Una volta ottenuta la CHIAVE API ripulita restituita da Discourse, devi decodificarla. Per fare ciò, puoi usare la decodifica JavaScript con le chiavi private. Fondamentalmente, usi la tua chiave privata (generata nel primo passaggio sopra) per decodificare la CHIAVE API ripulita. C’è qualche esempio JavaScript nel gist di GitHub che ho citato sopra: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
Dopo aver eseguito il tuo codice di decodifica, hai il token stesso, che ora puoi usare per effettuare chiamate API autenticate per conto dell’utente.
Sesto: Usa il token (cioè la CHIAVE API finale, ripulita e decodificata) per effettuare chiamate API per conto dell’utente
Con quel token, sembra che non sia necessario inserire il nome utente nella chiamata API. Trovo che l’intestazione seguente sia sufficiente quando la includi nelle tue chiamate GET, POST, PUT, ecc.:
headers: {
"User-Api-Key": [il token]
}
E con questo, speriamo tu abbia un metodo di autenticazione per utente funzionante per interagire con Discourse.
7 Mi Piace
Quali sono le implicazioni di sicurezza dell’aggiunta di elementi a allowed_user_api_auth_redirects? Ho una persona che chiede di aggiungere una stringa per supportare l’integrazione NextCloud.
1 Mi Piace