Un utente non amministratore può emettere la propria chiave API?

Sviluppatore
1

Ciao :waving_hand:,

Sto creando un’azione GitHub per pubblicare sul forum Discourse.
Ho trovato l’API per i post, ma la documentazione afferma che gli utenti di Discourse devono creare una chiave API dal pannello di amministrazione, anche se gli utenti non amministratori non hanno accesso a tale pannello. Ecco le mie domande:

  • La chiave API è prevista anche per gli utenti non amministratori?
  • Se sì, come possono gli utenti non amministratori creare la propria chiave API?
  • Se sì, per abilitare la chiave API per gli utenti non amministratori, sono necessarie alcune impostazioni?
    • La pagina delle preferenze del forum non ha un’interfaccia per creare una chiave API. Quindi immagino che esistano delle impostazioni che consentano agli utenti di generare le proprie chiavi API.

Grazie in anticipo! :folded_hands:

1 Mi Piace
2

Ciao @KengoTODA, benvenuto qui! :slight_smile: :wave:

User API keys specification sarà utile per ciò che hai descritto.

3 Mi Piace
3

Grazie! Ho controllato la sezione ‘Flusso di generazione della chiave API’.

Ho capito che è destinato alle applicazioni web che possono fornire un URL auth_redirect.
Esiste un metodo consigliato per CLI o GitHub Actions?

4

Se si tratta di un’azione GitHub, è probabile che sia meglio creare una chiave API con ambito limitato, che consenta solo le azioni necessarie, ma sì, per creare questa chiave è necessario essere amministratori.

4 Mi Piace
5

Per i programmi CLI, se necessario, puoi avviare un server web locale e utilizzare un URL http://localhost:XXXXX/callback. L’app fa qualcosa di simile.

3 Mi Piace
6

Ok, ci provo, grazie per il supporto!

1 Mi Piace
7

Puoi creare una chiave API per l’utente seguendo Generate User API Keys for testing

2 Mi Piace
8

Sto lavorando su questo branch e ho eseguito con successo il comando utilizzando localhost come URL di reindirizzamento. Tuttavia, dopo aver cliccato sul pulsante per autorizzare, la pagina https://meta.discourse.org/user-api-key ha segnalato un errore JS e non è stato possibile completare l’operazione. Lo script ruby funziona, ma fallisce anch’esso quando aggiungo il parametro auth_redirect.

Di seguito l’eccezione riportata nella console del browser:

Uncaught TypeError: Cannot set property 'isReadOnly' of undefined
    at Function.createCurrent (_application-42d4413fabab7a4b12e0c25fb01f736af560aa283089071a8493f37c9b042a4a.js:44867)
    at Function.current (_application-42d4413fabab7a4b12e0c25fb01f736af560aa283089071a8493f37c9b042a4a.js:8816)
    at Object.initialize (_application-42d4413fabab7a4b12e0c25fb01f736af560aa283089071a8493f37c9b042a4a.js:70403)
    at Object.i.initialize (_application-42d4413fabab7a4b12e0c25fb01f736af560aa283089071a8493f37c9b042a4a.js:7001)
    at _ember_jquery-189e46ebcb33594b835e782fd1ce916ec750bc0cf980ebc4fb7796649161a18d.js:49660
    at i.each (_ember_jquery-189e46ebcb33594b835e782fd1ce916ec750bc0cf980ebc4fb7796649161a18d.js:67904)
    at i.walk (_ember_jquery-189e46ebcb33594b835e782fd1ce916ec750bc0cf980ebc4fb7796649161a18d.js:67891)
    at n.each (_ember_jquery-189e46ebcb33594b835e782fd1ce916ec750bc0cf980ebc4fb7796649161a18d.js:67858)
    at n.topsort (_ember_jquery-189e46ebcb33594b835e782fd1ce916ec750bc0cf980ebc4fb7796649161a18d.js:67758)
    at t._runInitializer (_ember_jquery-189e46ebcb33594b835e782fd1ce916ec750bc0cf980ebc4fb7796649161a18d.js:49667)

Allego uno screenshot dell’analisi del codice JS. Sembra che siteAttributes sia atteso come valore valido, ma risulta undefined. Se hai qualche suggerimento, fammelo sapere. Grazie!

Screenshot 2020-12-15 085706
Screenshot 2020-12-15 085706582×159 12.2 KB

9

Sto indagando su questo problema.

Lo JS genera un errore perché il metodo POST per /user-api-key restituisce 403 e il metodo build_not_found_page nel controller non invoca il metodo preload_anonymous_data che memorizza il valore precaricato.

Non è chiaro perché il server abbia risposto con 403 e <h1 class="title">Oops! That page is private.</h1> quando ho aggiunto il parametro auth_redirect. Ho provato a utilizzare lo stesso dominio per l’URL di callback (per verificare un problema di cross-site scripting) e il protocollo HTTPS, ma senza successo.

10

È necessario aggiungere il dominio (e il percorso) all’impostazione del sito allowed user api auth redirects.

Se stai eseguendo manualmente richieste HTTP, allora discourse://auth_redirect dovrebbe funzionare.

3 Mi Piace
11

Grazie, ho trovato la configurazione in site_settings.yml e ho capito perché la mia richiesta ha restituito un errore 403.

discourse://auth_redirect non funziona come previsto nel mio caso, quindi chiederò agli utenti di inserire manualmente il token crittografato, proprio come nel codice Ruby.

12

Nota per gli altri utenti: ho creato un modulo Node che può essere invocato tramite il comando npx. Genererà una chiave API con ambito write. Spero che ciò possa aiutare nel processo di configurazione dei sistemi che necessitano di un token API di Discourse.

2 Mi Piace
13

Modifica: Ciao @KengoTODA. Il tuo codice su GitHub mi è stato utile per indicarmi la strada giusta. Sto ancora sistemando alcune cose, poi scriverò brevemente come ho risolto il problema.

14

Il codice GitHub di @KengoTODA mi è stato di grande aiuto. Ora ho una versione funzionante per l’autenticazione degli utenti su base individuale per effettuare chiamate API a Discourse. Ho documentato i miei passaggi qui: User API keys specification - #45 by JQ331

2 Mi Piace