Several accounts, one sign-in
A customer is one person (or company) that owns several hosting accounts, each with its own plan. The person signs in to any one of them as usual and switches to the others from the header, without signing out and in again by hand.
A customer is a record that only groups accounts. It has no password of its own: every account keeps its own password, second factor, passkeys and IP allow-lists.
Who sets it up
The administrator, or a reseller for its own accounts, in the administrator panel under Users > Customers, or at the shell:
hitechcloudcli customers create "Acme Ltd" --owner admin
hitechcloudcli customers link 3 acme1 acme2
hitechcloudcli customers show 3
hitechcloudcli customers unlink acme2
hitechcloudcli customers delete 3
The rules:
- A customer has one owner, the administrator or one reseller, and links only accounts of that owner. A reseller never sees or links another reseller's or the administrator's accounts.
- An account belongs to at most one customer.
- Deleting a customer, or unlinking an account, leaves the accounts as they are. Deleting an account removes its link.
- An account linked to a customer cannot be moved to another owner until it is unlinked.
- If a reseller is deleted, the customers it owned stay in the list until the administrator deletes them.
The same is available as a REST API in the administrator panel (an API token of the administrator or of a reseller, which is scoped to its own customers; a hosting account's token is refused). Every POST and DELETE is written to the audit log:
GET /api/customers[?owner=admin|<reseller>] | list |
POST /api/customers {"name", "note", "owner"} | create (201) |
GET /api/customers/{id} | the customer and its accounts |
DELETE /api/customers/{id} | delete; the accounts stay |
POST /api/customers/{id}/accounts {"accounts": [...]} | link |
DELETE /api/customers/{id}/accounts/{username} | unlink |
Another owner's customer answers 404, the same as one that does not exist. On Users the list gains a Customer column and a filter by customer (or No customer) as soon as one account is linked.
Switching accounts
When your login has more than one linked account in good standing, the header of the panel shows a list of the other accounts. Pick one:
- The session of the account you are leaving ends.
- The account you enter is checked as a sign-in checks it: it must be in good standing, its IP allow-lists must accept your address, and it must not be locked after failed sign-ins.
- If that account has a second factor (an authenticator app or an e-mail code), the sign-in form asks for its code, with the same limits as any sign-in.
- The panel opens as that account, with a normal session.
A switch skips one thing only: the password of the account you enter. Everything else a sign-in asks for is still asked.
A login with a single account, or whose other linked accounts are suspended, sees no switcher and nothing changes.
Team members cannot switch accounts, and neither can an administrator who is signed in as the account from the administrator panel. A plan without the account feature has no switcher.
What is recorded
- Each switch, and each refused one, is a line in
/var/log/hitechcloud/user/actions.logwith the rolecustomer: the account left is the actor and the account entered the subject. - Both accounts' activity logs show it, and the account entered sends its usual new sign-in notification.
Copy a database to another account
The icon beside the switcher opens Copy a database. It copies, or moves, a database of the account you are in to another account of the same customer:
- The source is always the account you are in. The target is chosen from the customer's other accounts, never typed.
- Choose the database, the target account and, if you like, how the new name ends. The copy is named with the target's prefix and belongs to the target.
- To move, choose Move and tick the box that says the database is removed from the source once it is copied. The source is dropped only after the copy has every table of the original.
The copy runs in the background and the page shows its state. Team members and administrators signed in as the account cannot use the page. Each run is a line in actions.log with the role customer, and a line in the account's activity log. The data is dumped with the source account's own database login and loaded with the target account's own login, never as root, and a database whose dump holds anything but its own statements (a USE, a GRANT, a name in another database, a DEFINER of another login) is refused before anything is made.
At the shell the same is:
hitechcloudcli customers db-copy 3 acme1_shop --from acme1 --to acme2 --move --confirm
hitechcloudcli customers db-copy-status c3-1792300000