Skip to content

Use supplied JWT_SECRET_KEY instead of always generating a random one - #520

Merged
dotsdl merged 4 commits into
mainfrom
fix-jwt-secret-key-519
Oct 20, 2026
Merged

dotsdl merged 4 commits into
mainfrom
fix-jwt-secret-key-519

Conversation

@dotsdl

@dotsdl dotsdl commented Oct 19, 2026

Copy link
Copy Markdown
Member

Fixes #519.

Summary

alchemiscale api and alchemiscale compute api discarded the JWT_SECRET_KEY / --jwt-secret they were given: the option's generate_secret_key callback ignored value and always returned a freshly generated key, which then overrode the environment settings via dependency_overrides. Every API process therefore signed tokens with its own private key, so tokens failed with 401 on other replicas and were invalidated on every restart.

Changes

  • alchemiscale/cli.py: the callback now passes through a supplied secret and only generates a random key when none is given. When it does generate one, it prints a warning to stderr, so a deployment missing the key no longer fails silently. Removed the stale "CONSIDER GENERATING…" comments in both api commands, since this now implements that behaviour. Updated the --jwt-secret help text.
  • alchemiscale/tests/integration/test_cli.py: tests that a secret supplied by option or env var is used unchanged with no warning, and that with no secret a warning is printed and each invocation gets a different random key.
  • docs/deployment.rst: note that JWT_SECRET_KEY must be set and shared across all API processes.
  • news/issue-519.rst: changelog fragment.

Testing

I couldn't run the full test suite here because the conda-only dependencies (openff) weren't available. Instead, I ran the jwt_params callback through CliRunner with those imports stubbed out:

  • --jwt-secret abc → abc
  • JWT_SECRET_KEY=fromenv → fromenv
  • unset → warning on stderr plus a different random key on each run

black --check passes on the changed files. CI needs to run the new tests in test_cli.py.


Generated by Claude Code

The --jwt-secret callback discarded the value resolved from the option or
JWT_SECRET_KEY and always substituted a freshly generated key, so every
API process signed tokens with its own key. Tokens were rejected by other
replicas and invalidated on restart.

Only generate a key when none is supplied, and warn on stderr when that
happens. Fixes #519.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MfKrZ874H9yYqThyTNK88t
@codecov

codecov Bot commented Oct 19, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.99%. Comparing base (91e4dac) to head (28d376b).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #520      +/-   ##
==========================================
+ Coverage   80.94%   80.99%   +0.05%     
==========================================
  Files          31       31              
  Lines        4932     4935       +3     
==========================================
+ Hits         3992     3997       +5     
+ Misses        940      938       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@dotsdl
dotsdl merged commit 608d02d into main Oct 20, 2026
6 of 7 checks passed
@dotsdl
dotsdl deleted the fix-jwt-secret-key-519 branch October 20, 2026 04:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JWT_SECRET_KEY is discarded: every API process signs with its own random key

2 participants