Conferma accesso API alle impostazioni del sito Limite di creazione

Sviluppatore
1

Sto lavorando a un’integrazione che pubblica e sincronizza argomenti correlati in Discourse tramite l’API. Per le diagnostiche di configurazione, vorrei leggere i limiti di creazione attuali del forum, in modo che l’integrazione possa verificare il contenuto prima di tentare di creare o aggiornare gli argomenti.

Le impostazioni a cui sto cercando di confermare l’accesso includono:

min_topic_title_length
max_topic_title_length
min_first_post_length
min_post_length
max_post_length
max_tags_per_topic
max_tag_length
tagging_enabled
create_tag_allowed_groups
tag_topic_allowed_groups

Ho controllato prima /site.json, che è accessibile e utile per indizi sulle funzionalità pubbliche, ma non sembra esporre queste impostazioni concrete sui limiti di creazione.

Con una chiave API per un utente bot non amministratore, questi hanno restituito 404:

/site_settings.json
/admin/site_settings.json
/admin/site_settings

Dopo aver reso l’utente bot un amministratore, questi hanno funzionato:

/admin/site_settings.json
/admin/site_settings

Utilizzando le intestazioni:

Accept: application/json
Api-Key: ...
Api-Username: discussbridge-bot
X-Requested-With: XMLHttpRequest

/site_settings.json ha ancora restituito 404.

Le mie domande:

  1. /admin/site_settings.json è il percorso API previsto per leggere le impostazioni attuali del sito?
  2. È necessaria la permissione di utente amministratore, o esiste un ambito API di sola lettura/granulare supportato per questo?
  3. /site_settings.json è deprecato, dipende da plugin, o non ci si aspetta che esista?
  4. Per le integrazioni, il modello consigliato è utilizzare una chiave di diagnostica/configurazione con capacità di amministratore per leggere le impostazioni, mentre si utilizza una chiave di pubblicazione con privilegi inferiori per il normale lavoro di sincronizzazione di argomenti/post?

L’obiettivo non è modificare le impostazioni tramite API, ma solo leggerle durante le diagnostiche di configurazione in modo che l’integrazione

2

  1. È /admin/site_settings.json

  2. Devi essere un amministratore, tranne per le impostazioni che hanno client: true, che possono essere trovate in /site/settings.json

Tutte le impostazioni di cui hai bisogno, tranne le ultime due, possono essere trovate in /site/settings.json.

Ma per i gruppi consentiti, il meccanismo funziona diversamente: se richiedi /site.json come utente specifico, puoi ispezionare can_tag_topics e can_create_tags.

  1. AFAIK /site_settings.json non è mai esistito.

  2. Penso che, per il tuo caso d’uso specifico, tu possa cavartela con un utente normale e usare il modello sotto #2.

3

Grazie @RGJ , questa era esattamente la distinzione mancante.

Ho testato i percorsi sul mio forum e posso confermare:

/site/settings.json

/site.json

funzionano con la mia chiave globale/admin attuale.

/site/settings.json espone i limiti numerici di creazione che mi servono, inclusi:

min_topic_title_length
max_topic_title_length
min_first_post_length
min_post_length
max_post_length
max_tags_per_topic
max_tag_length
tagging_enabled

E /site.json, quando richiesto come utente bot, espone:

can_tag_topics
can_create_tag

Sembra essere il pattern corretto per le diagnosi di configurazione.

Una domanda successiva: ho anche testato una chiave API granulare limitata alla pubblicazione di argomenti/post/categorie/tag:

categories:list
categories:show
posts:edit
posts:list
search:show
tags:list
topics:write
topics:update
topics:read
topics:status

Con quella chiave granulare:

/t/{topic_id}.json funziona
/tags.json          funziona
/categories.json    funziona

ma:

/site/settings.json  403
/site.json           403

Non vedo un ambito granulare evidente nell’interfaccia utente di amministrazione che consenta l’accesso a quei due endpoint a livello di sito.

Sto perdendo un ambito granulare o una configurazione URL consentita per /site/settings.json e /site.json?

Poiché le chiavi sono per un utente bot amministratore, ogni chiave è in grado di eseguire operazioni di amministrazione a livello utente. La chiave granulare limita solo quali endpoint API può chiamare.

Se non è così, la mia configurazione pratica durante i test sembra essere:

  1. una chiave di pubblicazione globale attuale
  2. una chiave di diagnostica globale per i controlli di configurazione che leggono le impostazioni del sito
  3. una candidata chiave di pubblicazione granulare per la sincronizzazione normale di argomenti/post/tag

Se la chiave di pubblicazione granulare si rivela sufficiente per la sincronizzazione normale, la chiave di pubblicazione globale originale potrebbe essere ritirata, lasciando:

  1. chiave di pubblicazione granulare per la sincronizzazione in esecuzione
  2. chiave di diagnostica globale/abilitata per amministrazione per i controlli di configurazione

Ma questo dipende dal fatto che la chiave granulare possa coprire tutte le operazioni di pubblicazione normali e se /site/settings.json / /site.json devono rimanere sul lato diagnostica.