Per quanto ne so, richiedere l’accesso amministratore per /site/settings.json e alcune informazioni in /site.json è un comportamento atteso di Discourse.
Discussion Bridge e integrazioni simili necessitano di un insieme limitato di informazioni sulla configurazione del sito per la diagnostica di routine, la pianificazione e la sincronizzazione. Al momento, questo potrebbe richiedere l’utilizzo di una chiave API associata a un amministratore. Una chiave admin di sola lettura impedisce le scritture, ma può comunque esporre tutto ciò che l’amministratore può leggere. Una chiave admin globale comporta un rischio inutilmente elevato per le operazioni quotidiane delle macchine.
Discourse potrebbe fornire:
Un ambito di chiave API granulare che conceda agli utenti di integrazione non amministratore l’accesso in lettura a un sottoinsieme appropriato e sicuro di /site.json e /site/settings.json; oppure
Un endpoint separato contenente le informazioni di configurazione non sensibili di cui le integrazioni hanno comunemente bisogno?
Discourse supporta già le chiavi API utente per gli utenti regolari, ma questo non risolve il caso in questione: una chiave può esercitare solo i permessi che l’utente associato possiede già. La richiesta è quindi specificamente per un’autorizzazione sicura non amministrativa ai dati di configurazione del sito limitati di cui le integrazioni hanno bisogno — non semplicemente un altro modo per generare una chiave.
L’obiettivo non è esporre le impostazioni amministrative private. È consentire a un account di integrazione non amministratore autorizzato di ispezionare la struttura del sito e le impostazioni operative di cui ha bisogno senza richiedere credenziali di livello amministratore di routine.
Ciò ridurrebbe il rischio di credenziali, supporterebbe integrazioni con privilegi minimi e renderebbe più facile operare in modo sicuro con strumenti macchina-a-macchina duraturi.
La nostra organizzazione ha membri che sarebbero felici di poter aiutare, ma per realizzare ciò che si sono offerti di implementare avrebbero bisogno di accesso amministrativo. Questo rende molto difficile fornire tutte le funzionalità e i servizi che potremmo benissimo implementare se solo avessimo un modo per definire in modo più granulare i permessi e gli accessi. Dobbiamo essere molto restrittivi nel concedere l’accesso per una serie di motivi, il che aumenta la pressione sugli amministratori a “fare tutto” quando ci sono impostazioni del sito non distruttive che alcuni dei nostri membri potrebbero facilmente aiutare a gestire… ma non possono farlo.
Potresti essere più specifico su quali impostazioni esatte del sito?
Un accesso in sola lettura senza restrizioni a tutte le impostazioni del sito sembra uno strumento un po’ troppo grezzo e includerebbe alcune impostazioni molto sensibili, tra cui le chiavi SaaS.
Potresti creare un plugin con accesso in sola lettura per gruppi a un insieme specifico di impostazioni del sito?
L’obiettivo è eseguire l’integrazione, accedendo e impostando le impostazioni richieste senza utilizzare una chiave con ambito globale utilizzata da un utente amministratore o una chiave con ambito granulare utilizzata da un utente amministratore.
La chiave con ambito granulare è di scarsa utilità per limitare l’accesso se devo comunque collegarla a un utente amministratore. Speriamo che questo chiarisca la situazione.
La tua suggerimento di utilizzare un plugin è valido, tuttavia non desidero un plugin con l’attuale set di funzionalità. Non voglio che l’utente Astro debba installare un plugin per connettersi a Discourse.
potresti riformulare la frase?