Skip to content

fix(auth): keep users with a filter out of setup - #5617

Merged
amir20 merged 1 commit into
mainfrom
fix/setup-filtered-users
Nov 9, 2026
Merged

amir20 merged 1 commit into
mainfrom
fix/setup-filtered-users

Conversation

@amir20

@amir20 amir20 commented Nov 8, 2026

Copy link
Copy Markdown
Owner

Setup applies to the whole instance, but the check only looked at roles. An empty roles: means all, so a user with a filter passed it too. Now a filter rules you out, same as pruneHost.

Users with a filter and every role lose setup after this. Unfiltered users and no-login installs don't change.

Also adds the roles vs filters rule to CLAUDE.md, and a line about it to the auth docs in all locales.

Tests

  • Go: make test (-race), staticcheck, tygo diff: pass
  • Docs: check-translations: pass
  • Behaviour: TestSetup_FilteredUserCannotWrite and Test_setupCanWrite_EveryLoginProvider fail on main (200/201/202/204 on every setup write, expected 403) and pass here. TestSetup_UnfilteredUserStillWrites passes. Forward proxy goes through the real router, simple and oidc call the check directly, and no-login is covered by the existing setup tests.
  • Fresh-context review: 2 Important, 0 Nit, 1 Pre-existing. Both Important were about a change I dropped from this PR. The Pre-existing one is unchanged here.
  • Not run: Docker e2e, a real agent, a second review after dropping that change. Setup only exists in server mode, so swarm and k8s aren't affected.

🤖 Generated with Claude Code

Setup applies to the whole instance but only checked roles. An empty roles
key means all, so a user confined by a filter passed as if they were an admin.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@claude

claude Bot commented Nov 8, 2026 •

Copy link
Copy Markdown

Claude finished @amir20's task in 48s —— View job


0 findings. Nothing to fix.

What I read

I read the whole diff: internal/web/setup.go, the new test file, CLAUDE.md, the English auth doc and all four translated mirrors.

Why it's correct

  • internal/web/setup.go:161 now also refuses h.restrictedUser(r). That function (internal/web/access.go:23-29) returns false under NONE and true only when the user has their own ContainerLabels, so a global --filter doesn't lock anyone out. No-login installs and unfiltered users behave as before.
  • The gate covers both the server and the UI. Every setup write goes through setupCanWrite: setup.go:308,389,449,532 and setup_agents.go:156,286,347. setupCanWriteUpdates (setup.go:171-176) delegates to it under a login. The UI flags read the same check: CanWrite/CanWriteUpdates at setup.go:238-240, and canAddHosts at index.go:236. So the UI stops offering what the server now refuses.
  • I found no other check of the form "holds every role" that would need the same fix: grep auth.All only hits setup.go:161 and a default in cloud_chat.go:131. Instance-wide routes (actions.go:199,248 prune, bulk_update.go:411, the cloud surfaces) already check restrictedUser.
  • All four login modes are covered. The tests send forward proxy through the real router and call simple and oidc directly (filtered_user_admin_test.go:89-101). The NONE path is unchanged.
  • The docs line is in docs/guide/authentication/simple.md and translated in de/es/fr/zh, with re-stamped sourceHash.
  • One behaviour change for existing users, which the PR body already calls out: a filtered user who holds every role loses setup access. That's the intended fix.

Not run

  • I couldn't run go test here because the command needed approval in this runner. I'm relying on the PR's reported runs.

@github-actions

github-actions Bot commented Nov 8, 2026

Copy link
Copy Markdown
Contributor

Try this PR without waiting for a release:

docker run -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 amir20/dozzle:pr-5617

Also on ghcr.io/amir20/dozzle:pr-5617 and as amir20/dozzle:pr-5617-alpine. Rebuilt on every push, currently 7faf63d.

@amir20
amir20 merged commit 1f7632a into main Nov 9, 2026
16 checks passed
@amir20
amir20 deleted the fix/setup-filtered-users branch November 9, 2026 14:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant