Repository navigation
fix(auth): require secret for internal service mode - #12
PranavaKCode wants to merge 5 commits into
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0e7fe789ee
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
FungousLand1941
left a comment
There was a problem hiding this comment.
I read through the auth/header changes and tests. The secret redaction and fail-closed internal-service path look solid. Two edge cases seem worth tightening before merge:
-
MantisClient.__init__still says that settinginternal_user_id/MANTIS_INTERNAL_USER_IDis sufficient for backend-to-backend auth. With this PR that guidance is incomplete; the error should mentioninternal_service_secret/MANTIS_INTERNAL_SERVICE_SECRETtoo so the first configuration failure points to the full contract. -
The PR says cookie authentication is unchanged, but
HttpClient.auth_headers()now raises wheneverinternal_user_idis present without a secret, even if a valid cookie was supplied. That means a process using cookie auth with a stale/ambientMANTIS_INTERNAL_USER_IDwill regress from working to raisingConfigurationError. If mixed cookie + internal configuration is intentionally fail-closed, I think it should be documented and covered by a test. If cookie should take precedence, the secret requirement probably needs to be gated to the internal-auth path.
The existing tests cover pure cookie and pure internal-service auth well; a mixed-auth regression test would make the intended precedence explicit.
|
Addressed the mixed-auth feedback in 74af9dc. A cookie now remains usable when an ambient internal user ID has no service secret; internal-only requests still fail closed. The README documents precedence when both complete methods are present, the constructor error names both required settings, and regression tests cover both mixed cases. Verified with Ruff, 74 passing tests, and git diff --check. Ready for a fresh review. |
|
@MantisCartography Could you review the current head |
|
@FungousLand1941 Your two auth edge cases are addressed in head |
|
Deployment-contract note for review: current MantisAPI main derives |
FungousLand1941
left a comment
There was a problem hiding this comment.
Rechecked the complete diff at 74af9dcb3efe6c9f38165875724900ee9aa8f5f3 following the replies to my original review.
Both concerns are addressed: the constructor error now names the internal user ID and service secret, and an ambient internal user ID without a secret no longer breaks cookie authentication. The new tests also cover the complete mixed-auth case, missing-secret fail-closed behavior, environment loading, and secret redaction in debug logs. The README states the intended precedence.
Local verification on Python 3.11: python -m pytest -q — 74 passed; ruff check . — all checks passed. The PR's Python 3.10/3.11/3.12 test jobs and build are green on this same head.
No remaining findings in the SDK changes from my earlier review. This verification uses mocked transport; it does not establish that external service credentials are provisioned or that production backend authentication has been exercised. The deployment-contract prerequisite described in the existing discussion remains a separate end-to-end check.
Description
MANTIS_INTERNAL_SERVICE_SECRETinto the SDK configurationX-Internal-Secretwith the existing internal-service marker and user IDMotivation and context
MantisAPI PR #2442 replaced the spoofable marker-only bypass with an authenticated
X-Internal-Secretcontract. SDK callers usingMANTIS_INTERNAL_USER_IDmust send that same provisioned secret or their requests fall through to browser authentication.Fixes #11.
This is intentionally fail-closed: the SDK accepts a provisioned secret but never derives or logs it. Cookie authentication is unchanged.
How has this been tested?
python -m ruff check .uv run --with pytest --with pytest-asyncio pytest -q(74 tests passed)git diff --checkScreenshots (if appropriate):
Not applicable; this is an SDK authentication contract change.
Types of changes
Checklist:
ruff check. There are no style warnings. [REQUIRED]pytest. All new and existing tests passed. [REQUIRED]