Allow authenticating with bearer token

[radon-at-beeper]

PLAT-34566

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• Documentation

  • Updated Alertmanager configuration guidance to include HTTP Bearer token authorization
  • Added best practices for secure credential handling

• Bug Fixes

  • Alert authentication now supports both bearer token and query parameter methods
  • Improved error handling and responses for authentication failures

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Walkthrough

Accepts Alertmanager webhooks authenticated either via query parameter secret or an Authorization: Bearer <token> header (both compared to APP_ALERTMANAGER_SECRET with timing-safe comparison); README updated with Alertmanager http_config.authorization.credentials example and guidance to prefer bearer tokens.

Changes

Cohort / File(s)	Summary
Documentation README.md	Reflowed text and replaced query-parameter auth example with an http_config.authorization.credentials / Bearer token example; added note that query-parameter secrets are not redacted in the Alertmanager UI and recommend Authorization header.
Server authentication src/routes.js	postAlerts now checks for APP_ALERTMANAGER_SECRET presence (500 if missing), accepts either ?secret= query param or Authorization: Bearer <token> header, uses timing-safe comparison (passwordsEqual) to validate, and returns 403 on failed auth; remaining alert handling unchanged.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20–30 minutes

• Review passwordsEqual timing-safe comparison implementation and its usage.
• Verify extraction/parsing of Authorization header (Bearer token) and handling of malformed headers.
• Confirm correct behavior when APP_ALERTMANAGER_SECRET is unset (logging and 500 response).
• Validate that existing alert parsing/room-resolution logic remains unaffected by the new auth flow.

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Allow authenticating with bearer token' directly matches the main change implemented in the PR: adding bearer token authentication support.
Description check	✅ Passed	The description references PLAT-34566, which is directly related to the changeset objective of fixing the password exposure issue via bearer token support.
Linked Issues check	✅ Passed	The code changes fully implement the requirements from PLAT-34566: postAlerts now accepts Authorization bearer tokens in addition to query parameters, Alertmanager config uses http_config.authorization.credentials, and README documents the bearer token approach with guidance against query parameters.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to PLAT-34566: README updates document bearer token usage, Alertmanager config changes use the recommended http_config approach, and postAlerts implements bearer token authentication as required.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch rr-bearer-secret

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 673cb7f and 1adf207.

📒 Files selected for processing (2)

• README.md (2 hunks)
• src/routes.js (1 hunks)

🔇 Additional comments (3)

src/routes.js (1)

8-23: Good dual authentication implementation.

The dual authentication approach (query parameter or Bearer token) correctly addresses the PR objective of keeping credentials out of the Alertmanager UI. The use of the authorized flag makes the logic clear and maintainable, and returning 403 for unauthorized requests is appropriate.

README.md (2)

22-26: LGTM - Clear configuration guidance.

The updated wording clearly explains that configuration works via environment variables for both manual and Docker deployments.

---

48-51: Good security guidance on authentication methods.

The documentation correctly warns users that the query parameter approach exposes credentials in the Alertmanager UI, which directly addresses the issue described in PLAT-34566. The recommendation to prefer the Authorization header is appropriate.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/routes.js (1)

24-35: LGTM! Authentication logic is sound.

Both query parameter and bearer token methods use timing-safe comparison correctly. The 403 fallback is appropriate.

Optional defensive improvement: Express may parse repeated query parameters (e.g., ?secret=a&secret=b) as an array. While unlikely to be exploitable (length check would fail or Buffer conversion would mismatch), you could add explicit type validation:

-        if (passwordsEqual(req.query.secret, expectedSecret)) {
+        const querySecret = typeof req.query.secret === 'string' ? req.query.secret : undefined
+        if (passwordsEqual(querySecret, expectedSecret)) {

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 1adf207 and e5276ee.

📒 Files selected for processing (2)

• README.md (2 hunks)
• src/routes.js (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• README.md

🧰 Additional context used

🧬 Code graph analysis (1)

src/routes.js (2)

src/app.js (1)

• routes (3-3)

tests/routes.tests.js (2)

• req (15-15)
• res (16-18)

🔇 Additional comments (2)

src/routes.js (2)

4-8: LGTM! Timing-safe comparison correctly implemented.

The passwordsEqual function properly guards against null/undefined values and length mismatches before calling crypto.timingSafeEqual. This addresses the timing attack concern from the previous review.

---

15-22: LGTM! Secret validation correctly implemented.

The guard ensures requests cannot be accidentally authorized when both req.query.secret and expectedSecret are undefined. The 500 response appropriately indicates server misconfiguration.