Sign-in Help Requests
The account panel has no "forgot password" link that emails a reset: an account controls whole domains, and a reset by email would make it only as safe as the mailbox that receives it. Instead, an account holder who cannot sign in asks you, and you give them a new setup link once you know it is them.
What the holder's page offers
Under the account panel's sign-in form, Can't sign in? opens a page in two parts. Try these first is the self-help the holder already has: a passkey in place of a forgotten password, a backup code in place of a lost authenticator app, a setup link they were given. Ask your provider is yours to decide, on Accounts › Sign-in Help Requests, in What the Page Offers (Edit):
| Choice | The page shows |
|---|---|
| Accounts can ask you for help (default) | A form: the username and a reason from a fixed list. The request lands on this screen. |
| Show your contact details | A text of yours, in Markdown, up to 500 characters: a help desk address, a phone number. |
| Show nothing | Only the self-help. |
The holder's side of the page is in the account docs: When you cannot sign in.
A request
A request says that someone could not sign in to an account, and why: Forgot the password, Lost the authenticator app, The passkey does not work or Another reason. There is no free text.
Three facts make the form safe to leave open to the internet:
- A request changes nothing on the account. No password stops, no session ends, so a stranger cannot use it to lock a holder out.
- The page answers the same for every username, including one that does not exist, so it does not reveal which accounts exist.
- It is throttled: 5 requests an hour from one address, 3 a day for one username.
An account has one open request at a time; asking again adds to it, and the screen shows how many times it was asked. When a request comes in, the panel:
- writes a warning to the
authsyslog channel; - mails the server's
rootmailbox, forwarded to the address ofserver:edit --admin-email(System mail); - pushes a notification to the devices of every admin user who has sign-in alerts on;
- mails the account's own system mailbox, so a holder who did not ask knows that somebody else did.
One round of mail and pushes goes out per 24 hours for the same request.
The panel does not know who filled in the form. Before you send a setup link, confirm with the account holder through a channel you already trust: the phone number or the address on file with you, not one the request gives you. The account docs tell holders to expect that call.
Answer a request
An open request shows in two places: at the top of Sign-in Help Requests, under Open Requests, with the reason, when and how often it was asked, and the address, country and browser it came from; and as a banner on every tab of the account's page, with the same facts. Each place offers the same answers:
| Answer | What it does |
|---|---|
| Reset credentials (the account's page) | The real fix: removes the password, ends every session, and gives you a single-use setup link to hand over (Accounts). Closes the request as Setup link issued. Not offered for a suspended account. |
| Mark as handled | Closes the request as Handled, for when you helped the holder another way. Nothing on the account changes. The account is told. |
| Decline | Closes the request as Declined, with an optional reason of up to 1,000 characters that is mailed to the account's system mailbox. Nothing on the account changes. |
On the command line:
elpanctl server:sign-in-help:list [--all] [--format=tsv|jsonl]
elpanctl server:sign-in-help:decline <id> [--reason=<text>]
elpanctl account:reset <username>
server:sign-in-help:list prints the open requests with their ID, account,
reason, how many times and when they were asked, and the address; --all
adds the closed ones, up to 500. account:reset is the command behind
Reset credentials; account:reset-password sets a generated password
instead and closes the request as New password set. There is no command
for Mark as handled.
A request also closes on its own when the account signs in (its own sign-in, not an impersonated one, see Act in an account), when its password changes, or when a setup link is issued or used, whatever the reason. An unanswered request expires after 14 days.
The history
Closed Requests, under the open ones, keeps every closed request for 90 days: the account, the reason, when it was asked, the outcome (The user signed in, Setup link issued, New password set, Handled, Declined with its reason, Expired), and who answered it. Requests and answers are rows of the Auth Log as well, and of the holder's own account activity.