Confirmando acesso à API para Configurações do site de limite de autoria

Dev
1

Estou trabalhando em uma integração que publica e sincroniza tópicos companheiros no Discourse via API. Para diagnósticos de configuração, gostaria de ler os limites atuais de autoria do fórum para que a integração possa verificar o conteúdo antes de tentar criar ou atualizar tópicos.

As configurações que estou tentando confirmar o acesso incluem:

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

Primeiro verifiquei /site.json, que é acessível e útil para dicas de capacidade pública, mas parece não expor essas configurações concretas de limite de autoria.

Com uma chave de API para um usuário bot não administrador, estes retornaram 404:

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

Após tornar o usuário bot um administrador, estes funcionaram:

/admin/site_settings.json
/admin/site_settings

Usando cabeçalhos:

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

/site_settings.json ainda retornou 404.

Minhas perguntas:

  1. /admin/site_settings.json é o caminho de API esperado para ler as configurações atuais do site?
  2. É necessária permissão de usuário administrador, ou há um escopo de API somente leitura/granular suportado para isso?
  3. /site_settings.json está obsoleto, depende de plugin, ou não se espera que exista?
  4. Para integrações, o padrão recomendado é usar uma chave de diagnóstico/configuração com capacidade de administrador para ler configurações, enquanto usa uma chave de publicação com menos privilégios para o trabalho normal de sincronização de tópicos/posts?

O objetivo não é alterar configurações via API, apenas lê-las durante os diagnósticos de configuração para que a integração

2

  1. É /admin/site_settings.json

  2. Você precisa ser um administrador, exceto para configurações que têm client: true; essas podem ser encontradas em /site/settings.json

Todas as configurações que você precisa, exceto as duas últimas, podem ser encontradas em /site/settings.json.

Mas, para grupos permitidos, o mecanismo funciona de maneira diferente: se você solicitar /site.json como um usuário específico, poderá inspecionar can_tag_topics e can_create_tags.

  1. AFAIK /site_settings.json nunca existiu.

  2. Acho que, para o seu caso de uso específico, você pode se virar com um usuário regular e usar o padrão sob o nº 2.

3

Obrigado, @RGJ, essa era exatamente a distinção que faltava.

Testei os caminhos no meu fórum e posso confirmar:

/site/settings.json

/site.json

funcionam com minha chave global/admin de bot atual.

/site/settings.json expõe os limites numéricos de criação que preciso, incluindo:

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 solicitado como usuário bot, expõe:

can_tag_topics
can_create_tag

Isso parece ser o padrão correto para diagnósticos de configuração.

Uma pergunta de acompanhamento: também testei uma chave de API granular com escopo para publicação de tópicos/postagens/categorias/tags:

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

Com essa chave granular:

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

mas:

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

Não vejo um escopo granular óbvio na interface administrativa que permita acesso a esses dois endpoints de nível de site.

Estou perdendo algum escopo granular ou configuração de URL permitida para /site/settings.json e /site.json?

Como as chaves são para um usuário bot administrador, cada chave tem capacidade administrativa no nível de usuário. A chave granular apenas restringe quais endpoints de API ela pode chamar.

Se não, minha configuração prática durante os testes parece ser:

  1. uma chave global de publicação atual
  2. uma chave global de diagnóstico para verificações de configuração que leem as configurações do site
  3. uma chave granular de publicação candidata para sincronização normal de tópicos/postagens/tags

Se a chave granular de publicação se mostrar suficiente para sincronização normal, a chave global de publicação original poderia ser descontinuada, restando:

  1. chave granular de publicação para sincronização em tempo de execução
  2. chave global/administrativa de diagnóstico para verificações de configuração

Mas isso depende de a chave granular conseguir cobrir todas as operações normais de publicação e se /site/settings.json / /site.json precisam permanecer no lado dos diagnósticos.