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.
Einen granulareren API-Schlüssel-Bereich, der Nicht-Admin-Integrationsnutzern Lesezugriff auf eine geeignete, sichere Teilmenge von /site.json und /site/settings.json gewä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.
In unserer Organisation gibt es Mitglieder, die sehr gerne helfen möchten, aber um das zu tun, was sie angeboten haben zu implementieren, würden sie Administratorzugriff benötigen. Das macht es sehr schwierig, alle Funktionen und Dienste bereitzustellen, die wir sehr gut implementieren könnten, wenn wir nur eine Möglichkeit hätten, Berechtigungen und Zugriff granularer zu begrenzen. Wir müssen aus einer Reihe von Gründen sehr restriktiv sein, wie wir Zugriff gewähren, was den Druck auf Administratoren erhöht, „alles zu tun“, wenn es nicht-destruktive Seiteneinstellungen gibt, die einige unserer Mitglieder leicht helfen könnten zu verwalten… aber sie können es nicht.
Könnten Sie genauer spezifizieren, welche genauen Site-Einstellungen?
Ungefilterter schreibgeschützter Zugriff auf alle Site-Einstellungen wirkt etwas wie ein stumpfes Instrument und würde einige sehr sensible Einstellungen einschließlich SaaS-Schlüsseln umfassen.
Sie könnten ein Plugin mit gruppenbezogenem schreibgeschütztem Zugriff auf eine spezifische benannte Menge von Site-Einstellungen erstellen?
Das Ziel ist es, die Integrationsarbeit zu erledigen, indem auf die erforderlichen Einstellungen zugegriffen und diese konfiguriert werden, und zwar ohne einen globalen Schlüssel zu verwenden, der von einem Admin-Benutzer genutzt wird, oder einen feingranularen Schlüssel, der von einem Admin-Benutzer verwendet wird.
Der feingranulare Schlüssel ist weniger hilfreich, um den Zugriff zu beschränken, wenn ich mich dennoch an einen Admin-Benutzer binden muss. Hoffentlich hilft das weiter.
Ihr Vorschlag, ein Plugin zu verwenden, ist gut, jedoch möchte ich kein Plugin mit dem aktuellen Funktionsumfang. Ich möchte nicht, dass der Astro-Benutzer ein Plugin installieren muss, um eine Verbindung mit Discourse herzustellen.
könntest du das umformulieren?