Skip to content

Docker image requires manual gateway token entry despite nginx auto-auth setup #2

@frosty720

Description

@frosty720

UX improvement: Docker image requires manual gateway token entry despite nginx auto-auth setup

Expected Behavior

After authenticating with the basic auth credentials (admin/password), the Openclaw Control UI dashboard should automatically connect to the gateway. The nginx reverse proxy is configured to inject the Authorization: Bearer <token> header automatically, so users should NOT need to manually enter the OPENCLAW_GATEWAY_TOKEN.

Actual Behavior

The dashboard loads successfully after basic auth login, but shows "Disconnected" status. Users must manually copy-paste the gateway token into the "Gateway Access" section's "Gateway Token" field and click "Connect" to establish a connection.

Environment

  • Image: coollabsio/openclaw:latest (pulled 2026-01-31)
  • Docker version: 28.5.1
  • Host OS: Linux
  • Browser: Chrome

Steps to Reproduce

  1. Run the container with OPENCLAW_GATEWAY_TOKEN env var set:

    docker run -d \
      --name openclaw \
      -p 8080:8080 \
      -e ANTHROPIC_API_KEY=sk-ant-... \
      -e 'AUTH_PASSWORD=MyBigLongPassword' \
      -e OPENCLAW_GATEWAY_TOKEN=<generated-token> \
      -v openclaw-data:/data \
      coollabsio/openclaw:latest
  2. Access http://localhost:8080

  3. Log in with basic auth (admin / password)

  4. Observe dashboard loads but shows "Disconnected" in the "Snapshot" section

  5. The "Gateway Token" field in "Gateway Access" section is empty

  6. Must manually paste the token and click "Connect" to get "Connected" status

Evidence

The nginx config IS correctly configured inside the container:

location / {
    auth_basic "Openclaw";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:18789;
    proxy_set_header Authorization "Bearer <token>";
    ...
}

Despite this, the Control UI doesn't seem to use the proxied auth header and requires manual token entry.

Impact

This defeats the purpose of having nginx handle authentication. Users shouldn't need to know or manage the OPENCLAW_GATEWAY_TOKEN env var in the UI - it should be transparent.

Possible Cause

The Control UI may be attempting to connect directly to the WebSocket endpoint (ws://localhost:8080) from the browser rather than going through the nginx proxy, bypassing the injected Authorization header.

Suggested Fix

The Control UI should either:

  1. Trust the authenticated session from nginx and not require a separate gateway token, OR
  2. Use the proxied connection which includes the Authorization header automatically

Note: This was discovered during testing of the main openclaw Docker image (not the browser sidecar compose setup).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions