Skip to content

Password reset and bulk whitelist (setpassword / addalltowhitelist) #83

Description

@cagatay-softgineer

Found by diffing pzctl against the game's documented command list, prompted by the pz-admin survey (#77-#79). Syntax quoted from media/lua/shared/Translate/EN/UI.json on a real B42 install.

The gap

whitelist.py can adduser, but cannot reset a password or bulk-populate the whitelist. Two documented commands are missing:

/setpassword "username" "newpassword"    change a user's password
/addalltowhitelist                        add all currently-connected password users to the whitelist

("Add all the current users who are connected with a password to the whitelist, so their account is protected.")

Why each matters

setpassword - the single most common whitelist support request is "I forgot my password". Today the admin's only option through pzctl is to remove the account and re-add it, which is destructive and not obviously safe.

addalltowhitelist - the intended path for switching a running open server to a whitelisted one without locking out everyone currently playing. Doing that by hand for a populated server is impractical.

Security requirements - non-negotiable

whitelist.add_user already redacts via echo_as so passwords never reach the console log (adduser "bob" "********"). setpassword must use the same mechanism from the first commit. A password reset that echoes the new password into the console log, the SSE stream and the on-disk console log would be a regression against a property this project already established and tested.

Also: do not log the new password in the panel's own response body, and do not put it in a URL.

Scope

  • whitelist.set_password with echo_as redaction + a test asserting the plaintext never appears in the emitted line
  • whitelist.add_all for the bulk command
  • Panel: reset-password action on each whitelist row

Note

/changepwd "previouspassword" "newpassword" also exists but changes the caller's own password. Over RCON the "caller" is not a player, so it is likely meaningless here - the same reasoning that led to deliberately not implementing removeitem. Confirm before implementing; probably out of scope.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions