Ciao, vorrei chiedere informazioni su user_api_keys. Attualmente sto lavorando all’integrazione della nostra app per utilizzare le user_api_keys di Discourse per l’autorizzazione. La mia domanda è: c’è un modo per recuperare le user_api_keys tramite API?
Al momento, dopo aver effettuato l’accesso tramite /session.json e aver controllato il profilo utente corrente utilizzando /users/:username.json, possiamo vedere se l’utente ha user_api_keys o meno, ma non restituisce i valori effettivi:
Il motivo per cui voglio ottenere il valore di user_api_keys è evitare di richiedere all’utente di approvare l’autorizzazione una seconda volta dopo averla già autorizzata durante il primo accesso cliccando sul pulsante.
No, vengono mostrate una sola volta e poi viene memorizzato solo un hash.
La chiave API dell’utente dovrebbe essere memorizzata nella tua app, preferibilmente sul dispositivo dell’utente finale. L’intero scopo di una chiave API dell’utente è che essa abbia una “prova” di autorizzazione e che l’utente sia responsabile della sua memorizzazione.
Non credo sia possibile recuperare il valore di una chiave API tramite l’API. Discourse non salva le chiavi API non crittografate nel database. Anche se potessi recuperare il valore crittografato, non ci sarebbe modo di decifrarlo sulla tua applicazione.
Puoi spiegare meglio il tuo caso d’uso? Se una chiave API utente è già stata generata per un utente, non mi è chiaro perché debba approvare l’autorizzazione una seconda volta.
Rileggendo il mio post, vedo che non ho spiegato come è stata impostata la variabile $json per la richiesta. Il modo più semplice per capire come strutturare i dati è effettuare una richiesta per generare una singola chiave API utente con gli ambiti che si desidera utilizzare tramite l’interfaccia utente di Discourse, quindi osservare il valore del payload della richiesta inviato con la richiesta a /admin/api/keys:
Ciao @simon, grazie per la tua risposta. Permettimi di spiegare il nostro caso in modo più dettagliato.
Stiamo costruendo un’app mobile che si basa sulla logica backend degli endpoint di Discourse. Quando un utente accede tramite l’app, i dati di accesso vengono inviati all’API di Discourse tramite session.json, che restituisce un cookie. Questo cookie viene quindi utilizzato per reindirizzare il webview a /user-api-key/new, chiedendo all’utente di approvare l’autorizzazione. Dopo l’approvazione, il payload viene decifrato in chiavi API.
In questo caso, possiamo utilizzare le chiavi API come token globale all’interno dell’app mobile per accedere ad altri endpoint di Discourse. Tuttavia, quando l’utente effettua il logout, il token deve essere rimosso dallo stato globale in modo che non possa accedere a endpoint come la creazione di un nuovo argomento.
La mia domanda riguarda questo argomento: come possiamo verificare se un utente ha già user_api_keys e se sono ancora attivi? Se le chiavi esistono e sono attive, l’utente dovrebbe essere in grado di utilizzarle dopo l’accesso. In caso contrario, l’utente dovrà creare nuove user_api_keys, il che richiederebbe l’approvazione nel webview.
Questo è il problema principale che sto affrontando.
Ho anche fatto riferimento al post Genera chiave API utente senza approvazione utente - #2 di simon, che inizialmente ho consultato per l’implementazione delle chiavi API. Tuttavia, il problema rimane lo stesso: quando controllo /admin/api/keys, non possiamo recuperare il valore delle chiavi API già salvate nel database o ottenere le chiavi API per utente. Credo che, per questa implementazione, dovremmo archiviare le chiavi API nel nostro database.
Forse potresti generare un token di sessione separato dalla chiave API. Usa quel token per indicare lo stato di accesso dell’utente. In questo modo non avresti bisogno di eliminare la chiave API quando l’utente effettua il logout.
Grazie per il tuo contributo a questo problema. Concordo sul fatto che sia meglio archiviare il token in due posti: innanzitutto, nello stato globale per verificare lo stato di accesso dell’utente e, in secondo luogo, nel database per archiviare le user_api_keys.
Ciao, grazie per il tuo suggerimento. Il motivo per cui non stiamo utilizzando Discourse Connect qui è che non stiamo collegando Discourse con altri siti web o altri luoghi. Tutta la funzionalità di accesso verrà gestita direttamente tramite Discourse e l’app interagirà solo con Discourse.
La tua app è un altro luogo. Sono abbastanza sicuro che tu voglia configurare la tua app in modo che sia un client Discourse Connect in modo che le persone possano accedere alla tua app accedendo a Discourse. Quindi la tua app può interagire con Discourse, penso. O forse non capisco come funzionano le app.
