Conversation
validate_key_format used int(hex_part, 16), which accepts a leading
sign, a 0x prefix, underscore separators, and whitespace. Enforce the
exact generated form with a [0-9a-f]{64} fullmatch in both copies
(api utils and auth middleware).
Fixes MemTensor#2427
🤖 Open Code ReviewTarget: PR #2429 🔍 OpenCodeReview found 1 issue(s) in this PR. 1.
|
✅ Automated Test Results: PASSEDAll tests passed (9/9 executed). memos_python_core/changed-repo-python: 9/9. Duration: 1s [advisory, non-gating] AI-generated tests on branch test/auto-gen-8d72db9ac3fbf0de-20260929004558: 50/50 passed — these do NOT affect the PR verdict; review the branch manually. Branch: |
Fixes #2427
Summary
validate_key_formatexists in two copies —src/memos/api/utils/api_keys.pyandsrc/memos/api/middleware/auth.py(the one gating every authenticated request) — and both validate the hex part withint(hex_part, 16), which accepts forms a generated key can never have:So the documented
krlk_<64-hex-chars>format is not actually enforced.Fix
Enforce the exact form
generate_api_key()produces with a fullmatch against[0-9a-f]{64}in both copies. Every currently-issued key still passes; only the non-canonical spellings stop doing so.Regression test
Added
tests/api/test_api_key_format.py(following the package-stub pattern used bytests/api/test_client.py):generate_api_key()-produced key still validatesruff check(repo-pinned 0.11.8) passes on all touched files.AI Disclosure