Logins and roles

Your hosted account comes with more than one kind of login, and they are not interchangeable: some open the control panel, some open a shell, and each reaches a different slice of what is yours. This page lists every kind, what it can and cannot do, who creates it and who ends it — so that when a colleague, an agency or an auditor asks for "access", you can hand over exactly the door they need.

If you only want the short version: your own two logins (the control panel and the oN.ftp shell) reach everything on your account; a colleague's control-panel login carries one of two roles, Client or Site operator, and sees only the sites of the Client it is attached to; a colleague's shell login exists in two kinds, the ordinary one for files and themes and the platform developer one for whole codebases — and only the last of these carries database access, which is why it belongs to a Client, never beside a Site operator login.

The six kinds of login at a glance

The rest of this page takes each in turn. The control-panel logins come first, because the role a panel login carries is what decides most of the questions people actually ask.

Two worlds, two kinds of login

The control panel and the shell are separate systems with separate passwords. Your own two logins share a name and start with the same password, but changing one never changes the other, and a colleague never gets both from one request: a panel login comes with no shell, and a shell login opens no panel. Keep that in mind when someone asks for "an account" — ask them which world they need to work in, and hand over one login for it.

Control-panel logins and their roles

What a role is

Every control-panel login carries one or more roles, and a role is a fixed list of permissions: which tasks its holder may queue, which pages they may open, which buttons they see. The lists are defined by BOA, identical on every server, and re-asserted every night and on every upgrade — so nothing anyone clicks in the panel changes what a role allows, your host included. What your host can change is which role a login holds. There are no custom roles: if a colleague needs a different mix, the answer is a different role, or a second login.

Your own login: the account owner

The login your host handed you in the welcome email is not "a Client login" — it holds three roles at once: the panel's admin role, the account manager role and the Client role. Together they make it the owner of the instance. In practice that means:

• Every site, whoever owns it, with every task: Verify, Backup, Restore, Disable and Enable, Clone, Migrate, Reset password (the one-time admin login link), Flush all caches, Rebuild registry, Run db updates, Convert to utf8mb4, Run health check, the migration source tasks, and Delete Site (after Disable). No colleague login can delete a site.
• Every backup, with every button on a site's Backups tab: Export and Get (which hand you the archive, database included), Delete and Restore.
• Platforms: the full Platforms list, creating a platform from your own codebase, verifying, locking and unlocking, deleting.
• Clients: creating Clients, editing them, deleting them, and the Allowed users list on each Client's edit form, where you associate an existing panel user with a Client or remove one — this is how you decide which sites a colleague sees.
• People: the list of every panel login on your account. You can add a user there, but you cannot give it a role — roles are assigned by your host only, and a login without a role sees nothing — so a new colleague login always goes through your host (below).
• Tasks: every task on the account, its full log, cancelling any queued task, retrying a failed one, and the bulk operations on the Sites list.

What it cannot do, by design: change what a role allows, log in as the panel's first account (that one belongs to your host and is never handed out), or reach anything outside your account — other customers' instances are simply not there.

The Client role: a colleague who can do what you can with a site

A colleague's login with the Client role, attached to your Client, sees your sites and can run every site task on them. In detail, it can:

• See the sites of its Client, their task lists and task logs, and the Client's own page (the Allowed users list, read-only).
• Create sites on your Client and edit a site's settings, including its aliases and redirects, its Encryption (SSL) setting and its cron intervals.
• Run every task a site offers: Verify, Backup, Restore, Disable, Enable, Clone, Migrate, Reset password, Flush all caches, Rebuild registry, Run db updates, Convert to utf8mb4, Run health check, the migration source tasks, the Git tasks on a Git-deployed site, importing or purging leftover copies, and the Backdrop, Grav and Textpattern upgrade and cutover tasks where those are in use.
• Use every button on the Backups tab: Export, Get, Delete and Restore. An exported archive carries the site's full database.
• Generate the admin login link with Reset password, and use it: the Log in to … button on the site page for 24 hours.
• Cancel a queued task and re-run a failed one on its Client's sites, whoever queued it — any task it could have queued itself, which on its Client's sites is every task but Delete Site.

It cannot: delete a site (that needs a permission only your own login holds), see the Platforms list or create, lock or delete a platform, create Clients or attach users, open the People list, or use the bulk operations on the Sites list.

This is the right role for a partner or a senior developer whom you would trust with a copy of the database and with the admin account of every site — because that is exactly what Backup, Export and Reset password give them.

The Site operator role: the day-to-day set without the sensitive tasks

A colleague's login with the Site operator role, attached to your Client, is built for the case where someone must operate your sites but must not be able to walk away with a database or log into a site as its administrator. It can:

• See the sites of its Client, their tasks and task logs, the Client's page, and the Platforms list (the platforms its Client has access to), which the Client role does not get.
• Create sites on the Client and edit a site's settings, aliases, Encryption and cron intervals.
• Run the routine tasks: Verify, Clone, Migrate, the migration source tasks, Flush all caches, Rebuild registry, Run db updates, Convert to utf8mb4, Run health check, Disable and Enable.
• Watch, cancel and retry the tasks of its Client's sites: for the task types it may run itself, it can cancel a queued one and retry a failed one whoever queued it, and it reads the logs.

And it cannot, each one deliberately:

• Backup, Restore or delete a backup — a backup archive carries the whole database, so the task and the Backups-tab buttons are withheld together.
• Export or Get a backup from the Backups tab — the tab still lists every backup, so the operator can see that they exist and when they were taken, but the buttons are not there and the links behind them answer access denied if typed in by hand.
• Reset password — no one-time admin login link, so no route into a site as its administrator. The site page shows the ordinary Go to … link instead of Log in to ….
• Delete a site, or run the Git, leftover and CMS-conversion tasks.
• Cancel or retry a task of a type it may not run — a Backup, Restore or Reset password task stays out of its reach whoever queued it.

Everything the operator can do is something a developer needs daily: build a staging copy with Clone, move a site to a newer codebase with Migrate, clear caches, run updates, switch a site off and on. Everything withheld is a way to copy data out, log in as someone else, or destroy something. That split is the whole point: ask your host for a site-operator login when a security review, a client contract or plain prudence says that the people who operate the sites should not be the people who can take their data home.

What every colleague login has in common

• It sees only its Client's sites. A colleague attached to Client A sees the sites of Client A and nothing of Client B, even on the same account. A task page or a task log of a site outside their Client is refused; so is queueing a task on such a site by guessing its address, and re-running one by guessing its number.
• Every task records who queued it. The task page says Queued by with the login name, and the task lists carry the same column, for the life of the site. When three people share one account, this is how you know who did what.
• It has its own password, changed from its own account page, and never expires. Forgotten passwords are reset by your host (the self-service reset link is switched off in the panel).
• It never comes with a shell. A panel login cannot connect over SSH or SFTP; if the same person needs files, that is a separate shell login, described below.

Getting a colleague a login

Your host creates the user, assigns the role and attaches it to your Client; tell them three things: the login name and email, Client or Site operator, and which Client the person works under. If you prefer, you can do the attaching yourself once the user exists — open the Client under Clients, click Edit, and use Associate a user to this Client; the same form's Remove column detaches a user again, which ends their view of your sites on the spot. Blocking or deleting the login altogether is your host's job.

One more detail worth knowing: creating a Client with an email address in the panel also creates a panel login for that address, carrying the Client role, but its password is never shown and no email is sent — so that route still ends with a request to your host to set the password, and it is simpler to ask for the login outright.

Shell logins

Your shell: oN.ftp

Your own limited shell reaches every site on your account with the full self-service tool set: Drush, Composer, Git, mybackup, the database clients — everything on shell and SFTP access. It is the one shell login that can do anything with any of your sites, which is exactly why it should never be handed to anyone else.

The extra shell login per Client: oN.<client>

The moment a Client owns at least one Drupal or Backdrop site, the server builds a separate shell login for it, oN.<client>, with a password left for you in your own ~/users/ folder. It sees the files and themes of that Client's sites and nothing else — no Drush, no Composer, no database client, no backup tool, no other Client's sites. It is the login for an outside developer working on a theme or a small custom module, and the one that fits beside a Site operator's panel login when that person also needs to touch files. The whole procedure — creating the Client, setting it as the site's owner, finding and forwarding the password, rotating it, ending it — is on extra accounts for your developers.

The platform developer login per Client: oN.<client>-dev

For a developer who maintains a whole codebase for you — Composer updates, the platform's own Drush — your host can switch on a second shell login for the same Client, oN.<client>-dev. It reaches every platform on which all the sites belong to that Client, with Composer and Drush inside each, and refuses any platform that also carries someone else's site. It is off unless you ask for it, created from a setting only your host can change, and gone within minutes when your host takes the Client off it. The developer's steps, the Drush window on Drupal 8 and newer platforms and the limits are on the same extra accounts page.

Who should hold what: the database line

Both shell logins belong to a Client — they are built from the Client that owns the sites, not from any panel login — so the question to ask before requesting one is what the person's panel login is allowed to do.

The platform developer login carries Drush, and Drush on a site is full read and write access to that site's database, plus a one-time admin login for the asking. That is the same power the Client role holds through Backup, Export and Reset password. So give oN.<client>-dev only to a person you would also give the Client role — and never as a companion to a Site operator login, because it would hand back through the shell exactly what the role withholds in the panel. A site operator who needs to work on theme files gets the ordinary oN.<client> login, which reaches the files and nothing underneath them.

The whole matrix

Passwords and lifecycles

Related

• Your account and first login — what your host handed you and the first things to do.
• Extra accounts for your developers — the two shell logins per Client, step by step.
• Backing up and restoring — the Backups tab and what its buttons hand out.
• Managing your sites — every task named above, in the order you meet it.
• Password and access problems — getting back into each login.