Aller au contenu

Cette page n’existe pas encore dans votre langue. Vous lisez le texte anglais.

Glossary

Role-based access control

One person opens the profiles they were given, another buys addresses, a third pays the bill. When everyone carries the owner's rights, the smallest mistake becomes everybody's problem.

Role-based access control is a rule that decides what a person may do by the role they hold, not by who they are.

The ladder and what it opens

Roles are ordered, and each one carries everything below it. The names are the ones the industry uses, and the boundaries are the ones the server actually applies.

  • Member and operator

    Work the profiles opened to them, and both add to and remove from the shared creatives the whole team draws from. Groups, addresses and schedules are not theirs to change.

  • Manager

    Plus the groups, the proxy library, saved flows, schedules and orders on the Proxy providers screen. Money and people are not theirs.

  • Admin

    Plus the three things the server keeps for admins alone: the money, the invites and roles, and the workspace history.

  • Owner

    Everything, and the one role that cannot be removed or narrowed by anybody else.

Role is compared rather than matched

A route asks for a minimum role and anything above it passes, so an admin never needs a second permission to do a manager job.

A role the server does not recognise lands below the lowest role, which means a typo grants nothing instead of granting everything.

Where the line falls

ActionLowest role that passes
Open and work a profile that was sharedMember
Create, rename and delete groupsManager
Add, edit or delete an address in the shared libraryManager
Change IP of a shared mobile lineManager
Pull the whole proxy library to a second machineManager
Save a flow or a schedule for everyoneManager
Order traffic on the Proxy providers screenManager
Invite, remove or change a roleAdmin
Read the workspace historyAdmin
Change the plan or the cardAdmin

A program key carries a role too

A key belongs to a person, so it answers to that person's role and to its own narrower list of things it may touch.

Both are read on the same request, and the narrower of the two wins. A read-only key on an admin account still reads only.

Roles and groups answer different questions

A role answers what a person may change. A group answers which profiles they can see and open at all.

The two multiply rather than replace each other, so a manager narrowed to one client still edits the library and still sees one client.

Often confused with

  • Signing in

    A second step at the door proves who arrived. A role decides what that person is allowed to touch once they are inside.

  • Scopes on a program key

    A scope narrows one key. A role belongs to the person and applies to every key they ever create.

  • Group access

    Groups narrow what a person can see. A role narrows what they can change, and the two are set in different places.

What this does not do

  • It does not let you write your own role. The ladder is fixed, and the only choice is which role a person gets.
  • It does not vary by group. Somebody cannot be an admin over one client and an operator over another, because the role belongs to the whole space.
  • It does not hand a profile over. A role decides what may be changed; a profile still has to be shared with the person before they see it.
  • It does not narrow the owner. Whoever created the space sees all of it, and an admin cannot lock them out of their own account.

Check it

Each boundary above is one line in a file you can open.

The ladder, the numeric order and the roles that can be assigned
apps/server/src/common/roles/workspace-roles.ts
The role is resolved after sign-in and compared, and an unknown role scores nothing
apps/server/src/common/roles/roles.guard.ts
The lowest role is turned down for the proxy library and for Change IP
apps/server/test/paid-access.js · apps/server/test/proxy-secret.js
Group access is read where profiles are listed and where one is opened
apps/server/test/group-access.js

Questions

Can a manager see the money?
No. Billing and the workspace history start at admin, while the list of who is in the space and with which role stays open to everyone inside it.
What happens if a role name is unknown?
It resolves below the lowest role and satisfies nothing. That is deliberate: a broken name has to fail closed, not open.
Does an API key get around a role?
No. The key is resolved to its owner, the owner's role is compared as usual, and the scopes written on the key narrow it further.
Why can an operator use an address but not edit it?
Using one is needed to start a profile at all. Editing or rotating one changes what colleagues are working through right now.
Can I stop somebody from deleting profiles?
Sharing never grants it. A profile is deleted by whoever created it or by an admin, and anybody else is told there is no such profile.

Give each person the role they need

Invite a colleague, give them a role, and narrow them to the groups that are theirs.