Bestätigung des API-Zugriffs auf die Site-Einstellungen für die Authoring-Grenze

Entwickler
1

Ich arbeite an einer Integration, die Begleitthemen über die API in Discourse veröffentlicht und synchronisiert. Für die Einrichtungsdiagnose möchte ich die aktuellen Autorengrenzen des Forums lesen, damit die Integration den Inhalt vorab prüfen kann, bevor sie versucht, Themen zu erstellen oder zu aktualisieren.

Die Einstellungen, auf die ich Zugriff prüfen möchte, sind:

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

Ich habe zuerst /site.json überprüft, das zugänglich und nützlich für öffentliche Funktionshinweise ist, aber es scheint diese konkreten Einstellungen für Autorengrenzen nicht offenzulegen.

Mit einem API-Schlüssel für einen Nicht-Admin-Bot-Benutzer gaben diese 404 zurück:

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

Nachdem ich den Bot-Benutzer zum Administrator gemacht hatte, funktionierten diese:

/admin/site_settings.json
/admin/site_settings

Verwendete Header:

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

/site_settings.json gab weiterhin 404 zurück.

Meine Fragen:

  1. Ist /admin/site_settings.json der erwartete API-Pfad zum Lesen der aktuellen Site-Einstellungen?
  2. Ist Administratorbenutzerberechtigung erforderlich, oder gibt es einen unterstützten schreibgeschützten/granularen API-Bereich dafür?
  3. Ist /site_settings.json veraltet, pluginabhängig oder soll es nicht existieren?
  4. Ist für Integrationen das empfohlene Muster, einen adminfähigen Diagnose-/Einrichtungsschlüssel zum Lesen von Einstellungen zu verwenden, während ein weniger privilegierter Veröffentlichungsschlüssel für die normale Synchronisation von Themen/Beiträgen genutzt wird?

Das Ziel ist es nicht, Einstellungen über die API zu ändern, sondern sie nur während der Einrichtungsdiagnose zu lesen, damit die Integration

2

  1. Es ist /admin/site_settings.json

  2. Du musst Administrator sein, außer bei Einstellungen, die client: true haben; diese findest du in /site/settings.json

Alle Einstellungen, die du benötigst, mit Ausnahme der letzten beiden, findest du in /site/settings.json.

Bei erlaubten Gruppen funktioniert der Mechanismus jedoch anders: Wenn du /site.json als bestimmter Benutzer anforderst, kannst du can_tag_topics und can_create_tags überprüfen.

  1. Soweit ich weiß, hat /site_settings.json nie existiert.

  2. Ich denke, dass du für deinen speziellen Anwendungsfall mit einem normalen Benutzer auskommst und das Muster unter Nr. 2 verwendest.

3

Danke @RGJ , das war genau die fehlende Unterscheidung.

Ich habe die Pfade an meinem Forum getestet und kann bestätigen:

/site/settings.json

/site.json

funktionieren mit meinem aktuellen globalen/Admin-Bot-Schlüssel.

/site/settings.json gibt die numerischen Erstellungslimits aus, die ich benötige, einschließlich:

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

Und /site.json, wenn es als Bot-Benutzer angefordert wird, gibt aus:

can_tag_topics
can_create_tag

Das scheint das richtige Muster für Setup-Diagnosen zu sein.

Eine Folgefrage: Ich habe auch einen granular eingegrenzten API-Schlüssel für das Veröffentlichen von Themen/Beiträgen/Kategorien/Tags getestet:

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

Mit diesem granulareren Schlüssel:

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

aber:

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

Ich sehe keine offensichtliche granulare Berechtigung in der Admin-Oberfläche, die den Zugriff auf diese beiden site-weiten Endpunkte ermöglicht.

Habe ich eine granulare Berechtigung oder URL-Konfiguration für /site/settings.json und /site.json übersehen?

Da die Schlüssel für einen Admin-Bot-Benutzer sind, ist jeder Schlüssel auf Benutzerebene admin-fähig. Der granulare Schlüssel schränkt nur ein, welche API-Endpunkte er aufrufen darf.

Falls nicht, scheint mein praktisches Setup während des Tests folgendermaßen zu sein:

  1. ein aktueller globaler Veröffentlichungsschlüssel
  2. ein globaler Diagnoseschlüssel für Setup-Checks, die Site-Einstellungen lesen
  3. ein granularer Veröffentlichungsschlüssel-Kandidat für die normale Synchronisation von Themen/Beiträgen/Tags

Wenn sich der granulare Veröffentlichungsschlüssel als ausreichend für die normale Synchronisation erweist, könnte der ursprüngliche globale Veröffentlichungsschlüssel außer Dienst gestellt werden, sodass übrig bleibt:

  1. granularer Veröffentlichungsschlüssel für die Synchronisation zur Laufzeit
  2. globaler/admin-fähiger Diagnoseschlüssel für Setup-Checks

Aber das hängt davon ab, ob der granulare Schlüssel alle normalen Veröffentlichungsvorgänge abdecken kann und ob /site/settings.json / /site.json auf der Diagnoseseite bleiben müssen.