mirror of
https://github.com/HeyPuter/puter.git
synced 2026-10-18 01:30:16 +00:00
Provisioning a seat lets the owner supply any `email` that passes a format check. Puter then mailed a working temporary password to it. Nothing confirms the owner controls that address -- provisioned accounts are created with `requires_email_confirmation: false`, because the team is the trust anchor for the account, not for the mailbox. `resendActivation` reissues the credential and mails it again, up to the 20/day `team:reset-password` budget, so the same address can be hit repeatedly. The credential now stays out of the mail on both paths, which is what `resetMemberPassword` in the same file already does. Nothing is lost: all three routes return `temporary_password` to the owner, and the SDK has always documented that as the delivery -- "The returned password is shown once and is not retrievable afterwards -- deliver it out of band." The mail still goes out, naming the account and saying the team will supply the password. The two tests that pinned the old shape are inverted rather than deleted; one of them carried the rationale "without it this is the only copy", which the return value contradicts.