As I understand it, requiring admin access for /site/settings.json and some information in /site.json is expected Discourse behavior.
Discussion Bridge and similar integrations need a limited set of site configuration information for routine diagnostics, planning, and synchronization. Today this may require using an API key associated with an administrator. A read-only admin key prevents writes, but it can still expose everything the administrator can read. A global admin key carries an unnecessarily large risk for everyday machine operations.
Could Discourse provide either:
A granular API-key scope giving non-admin integration users read access to an appropriate, safe subset of /site.json and /site/settings.json; or
A separate endpoint containing the non-sensitive configuration information integrations commonly need?
Discourse already supports User API keys for regular users, but that does not solve this case: a key can only exercise permissions the associated user already has. The request is therefore specifically for safe non-admin authorization to the limited site configuration data integrations need—not simply another way to generate a key.
The goal is not to expose private administrative settings. It is to let an authorized non-admin integration account inspect the site structure and operational settings it needs without requiring routine admin-level credentials.
This would reduce credential risk, support least-privilege integrations, and make durable machine-to-machine tools easier to operate safely.
Our organization has members that’d love to be able to help out but to do what they’ve offered to help implement would require them to have admin access. This makes it very tough to provide all the features and services we could very well implement if only we had a way to more granularly scope permissions and access. We need to be very restrictive about how we grant access for a number of reasons, which increases pressure on admins to “do all the things” when there are non-destructive site settings that some of our members could easily help manage…but they’re not able to.
The goal is to do the work of the integration, accessing and setting the settings required without using a Global scoped key used by an admin user or using a granular scoped key used my an admin user.
The granular scoped key is less than helpful for limiting access if I still have to attach to an admin user. Hopefully that helps.
You suggestion of using a plugin is a good one however I don’t want a plugin with the current feature set. I don’t want the Astro user to have to install a plugin in order to connect with Discourse.