Genera chiave API utente senza approvazione dell'utente

Sviluppatore
1

Sto usando Discourse headless e sono in grado di ottenere informazioni sull’utente utilizzando la chiave API Admin, ma mi è stato consigliato di generare invece una chiave API utente per ciascun utente. Quindi sto provando a utilizzare questo metodo, ma non voglio che l’utente debba navigare in una nuova interfaccia utente per “approvare” la chiave API che sto creando per lui.

Quindi, la mia soluzione è inviare programmaticamente la conferma. Da una richiesta GET a ‘/user-api-key/new’, sono in grado di analizzare i dati dell’elemento ‘form’, ma non posso inviare una richiesta POST a ‘/user-api-key/’ perché riceverò un errore CSRF.

Ho disabilitato la protezione CSRF per Discourse Connect, ma ce n’è un’altra per api-key?
SiteSetting.discourse_connect_csrf_protection

In caso contrario, non utilizzerò le chiavi API utente finché non sarò in grado di crearle senza l’interruzione dell’interfaccia utente.

Grazie in anticipo!

Apparentemente, una soluzione che potrebbe funzionare esisteva in versioni precedenti, ma non vedo alcuna versione aggiornata di questo:

1 Mi Piace
2

Forse stiamo costruendo la stessa cosa :slight_smile: anche se la mia è solo parzialmente headless.

Sospetto che non ci sia, e che sia intenzionale.

Mi sono chiesto la stessa cosa, ma penso che nel mio caso andrà bene: non sto cercando di nascondere Discourse.

Una cosa da tenere a mente riguardo alle chiavi API utente rispetto alle chiavi API All User dell’amministratore è che per impostazione predefinita hanno limiti di frequenza diversi applicati: Available settings for global rate limits and throttling.

limite di frequenza API utente:
DISCOURSE_MAX_USER_API_REQS_PER_MINUTE : predefinito 20
DISCOURSE_MAX_USER_API_REQS_PER_DAY : predefinito 2880

limite di frequenza API amministratore:
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE : 60

Se la tua applicazione si connette a un sito Discourse self-hosted, puoi probabilmente sovrascrivere il limite di frequenza API amministratore. Se la tua applicazione si connette a istanze Discourse ospitate, i limiti di frequenza API utente offrono molta più flessibilità. Con il limite di frequenza API amministratore, finisci per dover mettere tutte le richieste in una coda limitata dalla frequenza.

Modifica: invece di utilizzare le Specifiche delle chiavi API utente per generare le chiavi, puoi utilizzare una chiave API amministratore per generare chiavi API utente. Questo aggira il problema che gli utenti devono approvare l’app.

Nota che la chiave pubblicata di seguito è per il mio dominio localhost, quindi non c’è rischio nel pubblicarla.

parametri chiave non escapati: {key:description:sally} {key:username:sally} {key:scopes:[scope_id:topics:write]} {key:scopes:[key:write]} {key:scopes:[name:write]} {key:scopes:[params:[topic_id]]} {key:scopes:[urls:[/posts (POST)]]} {key:scopes:[selected:true]}

❯ curl -X POST "http://localhost:4200/admin/api/keys" \
      -H "Api-Key: $api_key" \
      -H "Api-Username: system" \
      -H "Content-Type: application/json" \
      -d $json
{"key":{"id":29,"key":"f5c6307b51dd2882bde525dc9775fe7504b55c93fa40177b650f9e6b77a9d25b","truncated_key":"f5c6","description":"sally","last_used_at":null,"created_at":"2024-06-02T00:44:19.944Z","updated_at":"2024-06-02T00:44:19.944Z","revoked_at":null,"user":{"id":3,"username":"sally","avatar_template":"/user_avatar/127.0.0.1/sally/{size}/58_2.png"},"api_key_scopes":[{"resource":"topics","action":"write","parameters":["topic_id"],"urls":["/posts (POST)"],"allowed_parameters":{},"key":"write"}]}}

In entrambi i casi, ti rimane una chiave API che deve essere gestita in qualche modo. Presumo crittografata e salvata in un database.

5 Mi Piace
3

Stai usando React sul tuo frontend? Sono disponibile a trovare un modo per collaborare per ridurre la ridondanza e aumentare l’affidabilità del codice. Penso che l’autenticazione tramite SSO sia stata la parte più difficile. Quindi, speriamo che da qui in poi sia tutto liscio.

4

Sì, è un’app Remix/React Router. Quindi React sul frontend, Node sul backend.

Ci lavoro da anni. Inviami un messaggio qui se hai domande al riguardo.

Sto cercando di creare qualcosa che funzioni bene con i limiti di frequenza del sito Discourse ospitato. Quella è stata la parte difficile. Le chiavi API utente sembravano un modo possibile per gestirlo, ma c’è anche un limite di frequenza per indirizzo IP, quindi sono tornato a usare una singola chiave API e a mettere in coda tutte le richieste API.

1 Mi Piace
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.