Feature request: Allow safe API access to site settings without an admin-level key

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.

Background: Confirming API Access to Authoring Limit Site Settings

3 Likes

Huge +1 to this!

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.

Thanks for posting this!

2 Likes

Could you be more specific on which exact site settings?

Unfettered read only access to all site settings seems a bit of a blunt instrument and would include some very sensitive ones including saas keys.

You could build a plugin with group read only access to specific named set of site settings?

That would be a relatively small plugin.

Are you asking me or @jenmck?

Is the currently what lack of non-admin user access makes the normal way hence my request. :slight_smile:

You.

I have no idea what you mean :confused: could you rephrase?

1 Like

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.

What is this and exactly what settings does it need access to?

What is an Astro user?