Discourse Multi-Site API Key Pitfall: Key Created in the Wrong Database

Wapuu
1

Issue

When configuring the forum-cli tool for each VM to access the Wenpai Community (wpcommunity.com), API key authentication fails with HTTP 403:

ERROR: Post failed: ["You do not have permission to view the requested resource. The API username or key is invalid."]

Searching works, but posting fails. Eventually, even GET /categories.json returns 403.

Troubleshooting Process

  1. Tested with the old wenpai-dev API key → succeeded (200)
  2. Tested with the newly generated weixiaoduo API key → 403
  3. Both keys have identical format (64-character hex string); format is ruled out
  4. Key distinction: the old key was created earlier in the correct site’s admin backend; the new key was generated in bulk

Root Cause

wpcommunity.com uses Discourse’s multisite configuration, with its own dedicated database (wpcommunity) isolated from the default database (default). The bulk-generated API keys were created in the default database and thus are invalid for the wpcommunity.com site.

In Discourse’s multisite mode, each site maintains its own independent database, and API keys are not shared across databases.

Solution

Regenerated Global API keys for all VMs within the correct wpcommunity database. After deployment, all validations passed.

Follow-up Recommendations

  • When generating API keys for a Discourse multisite instance, ensure the admin URL matches the target site’s domain (e.g., https://wpcommunity.com/admin/api/keys).
  • If an API key returns 403, first verify whether it was created in the correct database.
  • Include the site name in the API key’s description field to aid future troubleshooting.
  • Exercise caution during bulk key operations—avoid accidentally revoking keys for other sites (in this incident, keys for the Cyber Forum were also mistakenly revoked).