Enable Badge SQL

:warning: Enabling Badge SQL entails security and performance risks.

Starting from Discourse 1.6 badge SQL can no longer be edited by admins unless explicitly enabled.

This change was made for a couple of reasons:

  1. Security: Allowing admins to enter SQL directly grants them raw access to the database. Generally, we opt that raw access to the database from the web UI as a feature you opt-in for. Even though the queries only return user_ids, an admin attacker can discover any information in the database using badge queries. For example, if column A of table Y has the letter A in it, return user_id 1 else 2.

  2. Performance: Getting badge SQL “just right” is an art; it is not something that is trivial for admins to do correctly. There is a huge amount of risk that people who are not experts can create enormous load on a database by entering bad SQL.

You can still get full authoring access by running:

./launcher enter app
rails c
> SiteSetting.enable_badge_sql = true

If you are an Enterprise customer, contact @team via a personal message to enable it. (You may also contact the team by emailing team@discourse.org).

Instead of SQL queries, our Standard and Business customers can see how to grant a custom badge through the API.

SiteSetting.enable_badge_sql = false (the default) disables all new badge SQL authoring. Existing badges will continue to work just fine with the SQL you have created. You can safely disable badge SQL after authoring your required badges.

All site settings are shadowed by globals… using DISCOURSE_ENABLE_BADGE_SQL: true in your container config will enable this.

Last edited by @JammyDodger 2024-05-25T11:21:59Z

Check documentPerform check on document: