Authentication Required

[hammer]

Hey I am probably doing something stupid but when I run agentsview serve and pop over to port 8080, I see the dashboard flash up but then immediately get replaced with an "Authentication Required" box. I have looked in the debug log and in ~/.agentsview/config.toml but do not see an auth token to paste into this box. I did not pass the --require-auth flag, so I'm also a bit confused about how I ended up here...

[wesm]

Taking a look now

[wesm]

It looks like a 403 forbidden error was mistakenly hitting the 401 auth needed path, so #563 will fix "auth required" box but you may still have a 403 error that needs to be pinned down. Here is what codex suggested as next steps once I merge the fix (you can try it by running make build from the main branch — I can cut a release with the fix later today after I merge some other PRs):

After updating to the version with the fix, could you try this?

1. Open exactly http://127.0.0.1:8080.

2. If you still see an error, please check the /api/v1/settings request in browser devtools Network tab:

   • 401 means auth is actually enabled.
   • 403 means the browser URL/host/origin is being rejected, not that you need a token.
   • A request going to some other host means the UI has a saved remote server URL.

3. In the devtools console, please run:

   localStorage.getItem("agentsview-server-url")

   If it prints a URL, try:

   localStorage.removeItem("agentsview-server-url")
   location.reload()

4. Please share:

   • the exact browser URL you opened
   • the /api/v1/settings status code
   • whether startup prints Auth enabled. Token: ...

With the fix, a 403 should no longer show the misleading “Authentication Required” prompt, so the status code should tell us which
path you’re hitting.

[hammer]

Thanks! I'm using this via exe.dev so there may be some issues with their VM and port forwarding that I'm hitting, I'll try out the fix and let you know what I see

[wesm]

Roger that. I just cut 0.31.0 which should be available soon

[wesm]

Codex follow-up based on the exe.dev / SSH port-forwarding detail: this sounds more like a forwarded-host/origin problem than real auth.

Hypotheses worth checking:

1. The SPA can load, but /api/v1/settings is rejected by the API Host check. Static routes are intentionally looser than /api/, so a browser URL like https://<something>.exe.dev/... or http://127.0.0.1:<forwarded-port> can show the dashboard briefly, then the first API call gets 403 Forbidden if the request Host does not match the server's configured host/port or configured public URL/origin.

2. SSH local forwarding can change the visible port. For example, if agentsview listens on the VM at 127.0.0.1:8080 but the browser opens http://127.0.0.1:18080, the browser sends Host: 127.0.0.1:18080; agentsview defaults only allow 127.0.0.1:8080 / localhost:8080.

3. exe.dev or its proxy may add X-Forwarded-* headers. We intentionally treat those requests as non-local, so /api/v1/settings will not return the auth token even if the backend connection reaches agentsview over loopback. If --require-auth is enabled, the token needs to come from the server console/config rather than from the remote settings response.

4. A saved frontend remote URL can send API requests somewhere unexpected. In devtools console, please check:

localStorage.getItem("agentsview-server-url")

If it prints a URL you did not intend to use:

localStorage.removeItem("agentsview-server-url")
location.reload()

Things that would help pin this down from the browser Network tab for /api/v1/settings:

• Exact browser URL opened.
• Status code and response body.
• Request Host and Origin headers.
• Whether X-Forwarded-For, X-Forwarded-Host, or Forwarded are present.
• Whether startup prints an auth token / auth enabled message.

If the status is 403, a likely workaround is to launch with the exact public browser origin trusted, for example --public-url https://<exact-exe-dev-host> or --public-origin http://127.0.0.1:<forwarded-port> depending on the URL being opened.

[mjacobs]

Hey 👋 I've also been playing around with remote/forwarding setups in my homelab. Following up on the 403 path, I might propose a self-contained improvement that can help for a class of remote/forwarded environments (exe.dev, Codespaces, Coder, WSL2 — cf. #440), i.e. beyond just the exe.dev scenario here.

IIUC, root cause (no auth case): when --require-auth isn't set, authMiddleware lets the request through but never marks it isRemoteAuth, so hostCheckMiddleware still runs the Host check. A forwarded browser Host like <x>.exe.dev or 127.0.0.1:<forwarded-port> isn't in buildAllowedHosts (internal/server/server.go:558), so /api/v1/settings gets a bare 403 Forbidden (server.go:619-623). The only escape today is knowing to pass --public-url <exact-origin>.

I think the more painful part is that nothing tells you that, i.e. 403 has no server log and no body explaining the cause (e.g. devtools required to diagnose like above).

I'd propose a few small improvements (three parts):

1. Server breadcrumb — on host-check rejection, log one line with the rejected Host, the allowed set, and a hint to pass --public-url; return a descriptive 403 body instead of bare "Forbidden". Fails closed exactly as today, just self-explaining.

2. Frontend — Avoid auth prompt for forbidden settings responses #563 routes 403 into the generic settings error. When status === 403, surface an actionable message ("server rejected this origin — restart with --public-url <origin>") in settings.svelte.ts.

3. Docs — short "Remote / forwarded access" section covering SSH port-forward + the --public-url flag.

I'd be happy to take this if the direction sounds right? I can reproduce the forwarded-host scenario locally behind a reverse proxy (and have a homelab scenario for an end-to-end check).

-Matt

[hammer]

Cloudera reunion! Thanks @mjacobs those sound like nice upgrades. Also I've been pushing exe.dev (@philz 👋 ) and agentsview separately on the @Open-Athena team so it's probably good for them to play nicely together...