Soweit ich das verstehe, ist es erwartetes Discourse-Verhalten, dass für /site/settings.json und einige Informationen in /site.json Administratorzugriff erforderlich ist.
Discussion Bridge und ähnliche Integrationen benötigen einen begrenzten Satz an Konfigurationsinformationen der Site für routinemäßige Diagnosen, Planung und Synchronisation. Heute erfordert dies möglicherweise die Verwendung eines API-Schlüssels, der einem Administrator zugeordnet ist. Ein schreibgeschützter Admin-Schlüssel verhindert Schreibvorgänge, kann aber immer noch alles offenlegen, was der Administrator lesen kann. Ein globaler Admin-Schlüssel birgt für alltägliche Maschinenoperationen ein unnötig großes Risiko.
Könnte Discourse entweder Folgendes bereitstellen:
- Einen granulareren API-Schlüssel-Bereich, der Nicht-Admin-Integrationsnutzern Lesezugriff auf eine geeignete, sichere Teilmenge von
/site.jsonund/site/settings.jsongewährt; oder - Einen separaten Endpunkt, der die nicht sensiblen Konfigurationsinformationen enthält, die Integrationen häufig benötigen?
Discourse unterstützt bereits Benutzers-API-Schlüssel für reguläre Benutzer, aber das löst diesen Fall nicht: Ein Schlüssel kann nur Berechtigungen ausüben, die der zugeordnete Benutzer bereits hat. Die Anfrage betrifft daher speziell eine sichere Nicht-Admin-Autorisierung für die begrenzten Site-Konfigurationsdaten, die Integrationen benötigen – nicht einfach nur eine andere Möglichkeit, einen Schlüssel zu generieren.
Das Ziel ist es nicht, private Administratoreinstellungen preiszugeben. Es geht darum, einem autorisierten Nicht-Admin-Integrationskonto zu ermöglichen, die Site-Struktur und Betriebseinstellungen zu inspizieren, die es benötigt, ohne dass routinemäßig Administrator-Credentials erforderlich sind.
Dies würde das Credential-Risiko reduzieren, Integrationen mit minimalen Berechtigungen unterstützen und den sicheren Betrieb von dauerhaften Machine-to-Machine-Tools erleichtern.
Hintergrund: Confirming API Access to Authoring Limit Site Settings