fix(znc): reset cloned account identity to the new username #2

Merged
thelion merged 1 commit from fix/znc-clone-identity into main 2026-08-22 14:04:14 +00:00
Owner

New BNC accounts were showing the template account's IRC information instead of their own.

Cause

ZNC's CloneUser copies the template account wholesale — that includes Nick, AltNick, Ident and RealName, not just the networks, servers, channels and modules we actually want. CreateBlocked only followed up with Set Password, Set Admin and Set BindHost, so every account provisioned through the clone path connected to IRC presenting the template's identity.

The bare AddUser path was never affected — ZNC derives those fields from the username itself there.

Fix

Set Nick, Altnick, Ident and RealName from the username after cloning. Clone-only, to avoid emitting redundant commands on the AddUser path.

Tests

The clone branch had no test coverage at all, which is how this went unnoticed. Added:

  • TestCloneResetsIdentityToNewUser — the full expected control-command sequence
  • TestCloneLeavesNoTemplateIdentity — template name appears only in CloneUser itself
  • TestBareAddUserSkipsIdentityResets — no redundant Sets on the bare path
  • TestCreateBlockedBindHostOverride — explicit bindHost wins over the configured default

Verified the first test fails against the old code and passes against the new. go build, go vet and the full go test ./... are clean.

Notes

  • This only affects accounts created from here on — existing cloned accounts keep the template identity until the same Set commands are run against them. A backfill is a separate job.
  • Per-network overrides are not covered. ZNC networks can carry their own nick/ident/realname that take precedence over the user-level values, and CloneUser clones networks too. If the template's networks set those explicitly they'd need SetNetwork as well — worth a look at the live template config.
New BNC accounts were showing the template account's IRC information instead of their own. ## Cause ZNC's `CloneUser` copies the template account wholesale — that includes `Nick`, `AltNick`, `Ident` and `RealName`, not just the networks, servers, channels and modules we actually want. `CreateBlocked` only followed up with `Set Password`, `Set Admin` and `Set BindHost`, so every account provisioned through the clone path connected to IRC presenting the template's identity. The bare `AddUser` path was never affected — ZNC derives those fields from the username itself there. ## Fix Set `Nick`, `Altnick`, `Ident` and `RealName` from the username after cloning. Clone-only, to avoid emitting redundant commands on the `AddUser` path. ## Tests The clone branch had no test coverage at all, which is how this went unnoticed. Added: - `TestCloneResetsIdentityToNewUser` — the full expected control-command sequence - `TestCloneLeavesNoTemplateIdentity` — template name appears only in `CloneUser` itself - `TestBareAddUserSkipsIdentityResets` — no redundant `Set`s on the bare path - `TestCreateBlockedBindHostOverride` — explicit bindHost wins over the configured default Verified the first test fails against the old code and passes against the new. `go build`, `go vet` and the full `go test ./...` are clean. ## Notes - This only affects accounts created from here on — existing cloned accounts keep the template identity until the same `Set` commands are run against them. A backfill is a separate job. - Per-network overrides are not covered. ZNC networks can carry their own nick/ident/realname that take precedence over the user-level values, and `CloneUser` clones networks too. If the template's networks set those explicitly they'd need `SetNetwork` as well — worth a look at the live template config.
ZNC's CloneUser copies the template account wholesale, including its
nick, altnick, ident and realname. CreateBlocked only followed up by
setting Password, Admin and BindHost, so every account provisioned via
the clone path connected to IRC presenting the template's identity
rather than its own.

Set Nick/Altnick/Ident/RealName from the username after cloning. The
bare AddUser path already derives these from the username, so this is
clone-only.

The clone branch had no test coverage at all, which is how this went
unnoticed; add cases for the identity reset, for the template name not
leaking outside the CloneUser command, for AddUser not emitting the
redundant Sets, and for an explicit bindHost overriding the default.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ircforever/managebot!2
No description provided.