Skip to content

Gateway: reject mixed trusted-proxy token config#58371

Merged
jacobtomlinson merged 2 commits intoopenclaw:mainfrom
jacobtomlinson:fix/fix-185
Mar 31, 2026
Merged

Gateway: reject mixed trusted-proxy token config#58371
jacobtomlinson merged 2 commits intoopenclaw:mainfrom
jacobtomlinson:fix/fix-185

Conversation

@jacobtomlinson
Copy link
Copy Markdown
Contributor

Summary

  • reject trusted-proxy gateway auth configs that also resolve a shared token
  • keep startup validation aligned for both config and environment sourced tokens

Changes

  • add a mutual-exclusion check in assertGatewayAuthConfigured(...) for trusted-proxy plus shared-token config
  • add regression coverage for both gateway.auth.token and OPENCLAW_GATEWAY_TOKEN

Validation

  • ran OPENCLAW_TEST_PROFILE=serial pnpm test -- src/gateway/auth.test.ts -t "rejects trusted-proxy mode when shared token comes from"
  • ran local agentic review via claude -p "/review" and added env-token coverage based on the feedback

Notes

  • residual risk or follow-up: this change keeps the fix at startup validation rather than changing unrelated runtime auth behavior

@jacobtomlinson jacobtomlinson requested a review from a team as a code owner March 31, 2026 12:35
@openclaw-barnacle openclaw-barnacle Bot added the gateway Gateway runtime label Mar 31, 2026
@jacobtomlinson
Copy link
Copy Markdown
Contributor Author

Incorporated the earlier proposed validation change here and preserved co-author credit in the commit.

@openclaw-barnacle openclaw-barnacle Bot added size: XS maintainer Maintainer-authored PR labels Mar 31, 2026
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Mar 31, 2026

Greptile Summary

This PR tightens gateway startup validation by making trusted-proxy mode and a shared token mutually exclusive, and removes the runtime loopback token-fallback path that created the ambiguity in the first place. The two concerns are addressed together: assertGatewayAuthConfigured now throws at server startup if both are present, and authorizeGatewayConnect no longer silently falls back to token auth for loopback requests. Test coverage is thorough — the parameterised it.each covers both the gateway.auth.token config path and the OPENCLAW_GATEWAY_TOKEN environment path, and a dedicated ordering test confirms that a missing trustedProxy config error still takes precedence over the token-conflict error.

Key changes:

  • auth.ts:325–329: mutual-exclusion guard added inside the trusted-proxy branch of assertGatewayAuthConfigured
  • auth.ts:460–479: ~24 lines of loopback token-fallback logic removed from authorizeGatewayConnect; all loopback requests now uniformly return trusted_proxy_loopback_source
  • auth.test.ts: local-direct describe block renamed; four previously passing token-fallback assertions updated to expect rejection; new startup-validation tests added

Confidence Score: 5/5

Safe to merge — no correctness issues remain; the mutual-exclusion guard is correct and the removal of the loopback fallback is consistent with the new policy.

All P1 concerns from prior review threads have been resolved: the startup validator now correctly rejects mixed configs, the loopback fallback code has been fully removed (eliminating the false-confidence from the old token-fallback tests), and the new ordering test confirms the trustedProxy presence guard still fires before the token-conflict guard. No new logic bugs or security gaps were identified in this pass.

No files require special attention.

Important Files Changed

Filename Overview
src/gateway/auth.ts Adds mutual-exclusion guard in assertGatewayAuthConfigured for trusted-proxy + token and removes the local-direct loopback token fallback from authorizeGatewayConnect; both changes are logically consistent and correctly implemented.
src/gateway/auth.test.ts Adds parameterised tests for both config-token and env-token rejection paths, adds an ordering test confirming missing-trustedProxy error takes precedence, renames the describe block, and updates all local-direct expectations from ok/token to rejected/loopback-source to match removed fallback.

Reviews (2): Last reviewed commit: "Gateway: fail closed for loopback truste..." | Re-trigger Greptile

Comment thread src/gateway/auth.ts
Comment thread src/gateway/auth.test.ts
@jacobtomlinson
Copy link
Copy Markdown
Contributor Author

@greptile review

@jacobtomlinson jacobtomlinson merged commit 6c679e5 into openclaw:main Mar 31, 2026
39 of 41 checks passed
@jacobtomlinson jacobtomlinson deleted the fix/fix-185 branch March 31, 2026 16:05
steipete pushed a commit to Mlightsnow/openclaw that referenced this pull request Apr 1, 2026
* Gateway: reject mixed trusted-proxy token config

Co-authored-by: boy-hack <w8ay@qq.com>

* Gateway: fail closed for loopback trusted-proxy auth

---------

Co-authored-by: boy-hack <w8ay@qq.com>
ivorclarke pushed a commit to brightfire/openclaw that referenced this pull request Apr 18, 2026
…proxy mode

Upstream PR openclaw#58371 removed the local-direct token auth fallback from
trusted-proxy mode and made auth.token mutually exclusive with
trusted-proxy. This left no auth path for loopback connections (CLI,
sub-agents) which connect via 127.0.0.1 with password auth.

When authorizeTrustedProxy returns trusted_proxy_loopback_source, fall
back to password auth if auth.password is configured and the client
provided a matching password. This restores local CLI access without
weakening the trusted-proxy security model for external connections.

Fixes: sub-agent spawns failing with 'unauthorized' on trusted-proxy
gateways.
ivorclarke pushed a commit to brightfire/openclaw that referenced this pull request Apr 18, 2026
Upstream PR openclaw#58371 removed the local-direct token auth fallback from
trusted-proxy mode, leaving loopback connections (CLI, sub-agents) with
no auth path. They are rejected by authorizeTrustedProxy with
trusted_proxy_loopback_source, and auth.token is banned in this mode.

Fix: when authorizeTrustedProxy returns trusted_proxy_loopback_source,
fall back to password auth if auth.password is configured and the client
provided a matching password. Rate limiting and failure recording apply.

Includes 3 new tests (61 total passing).
lovewanwan pushed a commit to lovewanwan/openclaw that referenced this pull request Apr 28, 2026
* Gateway: reject mixed trusted-proxy token config

Co-authored-by: boy-hack <w8ay@qq.com>

* Gateway: fail closed for loopback trusted-proxy auth

---------

Co-authored-by: boy-hack <w8ay@qq.com>
ogt-redknie pushed a commit to ogt-redknie/OPENX that referenced this pull request May 2, 2026
* Gateway: reject mixed trusted-proxy token config

Co-authored-by: boy-hack <w8ay@qq.com>

* Gateway: fail closed for loopback trusted-proxy auth

---------

Co-authored-by: boy-hack <w8ay@qq.com>
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request May 9, 2026
* Gateway: reject mixed trusted-proxy token config

Co-authored-by: boy-hack <w8ay@qq.com>

* Gateway: fail closed for loopback trusted-proxy auth

---------

Co-authored-by: boy-hack <w8ay@qq.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

gateway Gateway runtime maintainer Maintainer-authored PR size: S

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant