openclaw - ✅(Solved) Fix [Feature]: auth mode = none is required [1 pull requests, 1 participants]

jetcar · 2026-03-12T07:13:46Z

[openclaw] Feature request / improvement openclaw may be deployed inside a trusted internal network where no user authorization is required. At the moment the… Feature request / improvement openclaw may be deployed inside a trusted internal network where no user authorization is required. At the moment the only viable approach is to enable the trusted proxy option and place nginx in front of the service. This workaround feels unnecessary and awkward in environments such as Kubernetes. Hardcoding headers in a proxy does not meaningfully improve security, especially when authentication and authorization are already handled by external infrastructure components (API gateways, ingress controllers, service meshes, etc.), which are typically more robust and flexible. In our case, we already operate behind a gateway, so introducing an additional proxy layer solely to satisfy the trusted proxy requirement adds unnecessary complexity and operational overhead. It would be helpful if openclaw could support running in a mode suitable for trusted internal environments where authentication is intentionally disabled and security is delegated entirely to external components. # PR #43820: Gateway: allow explicit none auth on non-loopback binds - Repository: openclaw/openclaw - Author: lynnzc - State: closed | merged: False - Link: https://github.com/openclaw/openclaw/pull/43820 ## Description (problem / solution / changelog) ## Summary Describe the problem and fix in 2–5 bullets: - Problem: `gateway.auth.mode: "none"` could be set, but gateway startup still refused non-loopback binds unless token/password or trusted-proxy auth was configured. - Why it matters: trusted internal deployments (Docker/Kubernetes + external gateway/mesh auth) had to add unnecessary proxy auth workarounds. - What changed: runtime config validation and `openclaw gateway run` preflight now allow explicit `auth.mode=none` on non-loopback binds. - What did NOT change (scope boundary): shared-secret and trusted-proxy validation behavior is unchanged; security audit findings for exposed unauthenticated setups remain unchanged. ## Change Type (select all) - [ ] Bug fix - [x] Feature - [ ] Refactor - [x] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [x] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #43786 - Related #N/A ## User-visible / Behavior Changes - Users can now run gateway with `gateway.auth.mode: "none"` on non-loopback binds (for example `bind: "lan"`) without startup rejection in CLI preflight/runtime validation. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: macOS - Runtime/container: Node.js + pnpm - Model/provider: N/A - Integration/channel (if any): Gateway CLI/runtime - Relevant config (redacted): `gateway.bind=lan`, `gateway.auth.mode=none`, `gateway.controlUi.allowedOrigins=["https://control.example.com"]` ### Steps 1. Configure gateway with `bind: "lan"` and `auth.mode: "none"`. 2. Start gateway through CLI preflight path and runtime config resolution. 3. Verify startup does not reject due to non-loopback no-auth validation. ### Expected - Explicit `auth.mode=none` should start on non-loopback binds. ### Actual - Startup now succeeds; focused tests pass for CLI preflight + runtime config. ## Evidence Attach at least one: - [x] Failing test/log before + passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: - `src/gateway/server-runtime-config.test.ts` passes with lan + `auth.mode=none` allow case. - `src/cli/gateway-cli/run.option-collisions.test.ts` passes with `--bind lan --auth none`. - Edge cases checked: - Existing token-missing and bind/host validation cases still enforced. - What you did **not** verify: - End-to-end manual gateway startup against a live Kubernetes ingress. ## Review Conversations - [x] I replied to or resolved every bot review conversation I addressed in this PR. - [x] I left unresolved only the conversations that still need reviewer or maintainer judgment. If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers. ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Set `gateway.auth.mode` to `token` or `password` and configure matching

openclaw2026-03-12 07:13:46

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#43786•Fetched 2026-04-08 00:18:05

View on GitHub

Comments

Participants

Timeline

Reactions

Author

jetcar

Participants

jetcar

Timeline (top)

cross-referenced ×1labeled ×1

Feature request / improvement

openclaw may be deployed inside a trusted internal network where no user authorization is required. At the moment the only viable approach is to enable the trusted proxy option and place nginx in front of the service.

This workaround feels unnecessary and awkward in environments such as Kubernetes. Hardcoding headers in a proxy does not meaningfully improve security, especially when authentication and authorization are already handled by external infrastructure components (API gateways, ingress controllers, service meshes, etc.), which are typically more robust and flexible.

In our case, we already operate behind a gateway, so introducing an additional proxy layer solely to satisfy the trusted proxy requirement adds unnecessary complexity and operational overhead.

It would be helpful if openclaw could support running in a mode suitable for trusted internal environments where authentication is intentionally disabled and security is delegated entirely to external components.

Root Cause

Feature request / improvement

In our case, we already operate behind a gateway, so introducing an additional proxy layer solely to satisfy the trusted proxy requirement adds unnecessary complexity and operational overhead.

RAW_BUFFERClick to expand / collapse

Summary

Feature request / improvement

In our case, we already operate behind a gateway, so introducing an additional proxy layer solely to satisfy the trusted proxy requirement adds unnecessary complexity and operational overhead.

Problem to solve

overcomplicated setup of openclaw in trusted networks

Proposed solution

auth mode = none without any validations

Alternatives considered

No response

Impact

should fix issues when running in docker, k8s and other server like solutions

Evidence/examples

No response

Additional information

No response

extent analysis

Problem Summary

OpenClaw forces “trusted‑proxy” mode, which requires an upstream reverse‑proxy (e.g., Nginx) to inject X-Forwarded-User headers. In a trusted internal network the service should be able to run without any authentication – the surrounding gateway or service‑mesh already guarantees identity.

Goal: Add a configuration option that disables all auth checks (auth mode = none) and makes the middleware a no‑op.

Root Cause Analysis

The HTTP router always registers the AuthMiddleware which:
1. Verifies the request comes from a trusted proxy IP list.
2. Extracts a user from X-Forwarded-User (or similar) and aborts with 401 if missing/invalid.
There is no way to tell the server “skip auth completely”.
Consequently deployments in Kubernetes or Docker need an extra Nginx side‑car just to satisfy the check.

Fix Plan

1. Add a new config flag

# config.yaml (existing)
server:
  listen: ":8080"
  trusted_proxy: true   # existing flag

# NEW
  auth_mode: "none"     # allowed values: "trusted-proxy", "none"

Update the Go config struct:

type ServerConfig struct {
    Listen        string `mapstructure:"listen"`
    TrustedProxy  bool   `mapstructure:"trusted_proxy"`
    AuthMode      string `mapstructure:"auth_mode"` // "trusted-proxy" (default) or "none"
}

2. Adjust startup validation

func (c *ServerConfig) Validate() error {
    if c.AuthMode != "" && c.AuthMode != "trusted-proxy" && c.AuthMode != "none" {
        return fmt.Errorf("invalid auth_mode: %s", c.AuthMode)
    }
    return nil
}

3. Make the auth middleware conditional

func NewAuthMiddleware(cfg *ServerConfig) gin.HandlerFunc {
    // If auth is disabled, just return a pass‑through handler
    if cfg.AuthMode == "none" {
        return func(c *gin.Context) { c.Next() }
    }

    // Existing trusted‑proxy logic
    trustedIPs := loadTrustedIPs()
    return func(c *gin.Context) {

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#api #ssr #installation #tensor shape #autograd error #response parsing #generation error #database connection #vector store

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Feature]: auth mode = none is required [1 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #43820: Gateway: allow explicit none auth on non-loopback binds

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Validation Commands Run

Changed files

Summary

Problem to solve

Proposed solution

Alternatives considered

Impact

Evidence/examples

Additional information

extent analysis

Problem Summary

Root Cause Analysis

Fix Plan

1. Add a new config flag

2. Adjust startup validation

3. Make the auth middleware conditional

Still need to ship something?

RELATED_DISCOVERY

TRENDING