跳到主要内容

本页面暂无您所用语言的版本,您正在阅读英文原文。

Academy

Working as a team without shared passwords

Two people work on one account by sharing the profile, not the password. Each signs in as themselves, sees only the groups opened to them, and loses that access in one step.

第 7 课,共 14 课

The cost of a password in chat

A login pasted into a chat has no owner and no end. It stays in that history, on both machines and in their backups.

It also cannot be taken back. The only revocation left is a password change, which locks everybody out at once and tells the platform the account changed hands.

Seats instead of one shared login

Each person signs up for an account of their own, and an invite puts it into your workspace. From that moment the plan they work under is yours.

Profile quota, the proxy library, groups and the history all resolve against the owner. One team works inside one paid allowance and one bill.

Their own workspace stays theirs: they pick a workspace in the app's corner menu or the dashboard's Workspace row, and each has its own profiles and plan.

What each role opens

A role is a rank rather than a list of ticks. Every action on the server names the lowest rank it accepts, so a role the server does not recognise opens nothing. The owner can require everyone to turn on two-step sign-in: a member without it sees only the setup screen, and the team's profiles do not start for them.

RoleWhat it opensWhere it stops
OwnerEverything, billing and history includedCannot be removed or narrowed to groups
AdminInvites and roles, group access, billing, the whole historyDoes not change or remove the owner
ManagerGroups, the shared proxy library, flows and schedulesNo billing, no team, no history
Operator and memberTheir own profiles and those opened to themNothing shared to change, and no history

Groups narrow the view

A role applies to the whole workspace, so it cannot say that a contractor works on one client. Groups say that: on the Members screen press Groups next to the person, tick the groups they may see, and their list narrows to those groups.

The rule is read twice, when the list is built and when a profile is opened by its own identifier. A profile outside the allowed groups answers as if it had never existed.

  • An empty choice

    reads as no restriction, so unticking the last group widens the view, and the window says so: "Nothing picked: this person sees every group"

  • A profile in no group

    stays hidden once a restriction is set, or filing nothing would bypass the rule

  • The restriction itself

    belongs to your workspace and does not follow the person into their next one

Sharing a profile instead of a login

You tick colleagues under Share with the team in the profile menu and give each a level: can start, can edit or full access. It appears in their list marked shared with you, and unticking a name revokes access.

The fingerprint and the settings travel with the profile, so a colleague opens the same identity, not a copy; hand-picked fingerprint values and a chosen browser version stay where they were set. Cookies and logins travel through session sync where that is on (Sync sessions on the Engine screen).

One window holds a profile at a time. The second machine is told which one took it, and the hold lapses on its own when a machine goes quiet.

One proxy library

The proxy library belongs to the workspace, not to one computer, so everyone in it shares one. Attaching an address to a profile is how a colleague gets a way out.

The ordinary list carries the address, the label and a flag that a password is set, but not the password; pulling the whole library with its passwords belongs to a manager and above.

Where a password rests on disk, the system seals it on Windows only: on macOS the key ships inside the program, and on Linux the value is written as typed.

What History answers

Every action worth arguing about writes one row: who, what and when. A password handed out of the library is one such row.

Names are frozen as they stood that day, so renaming a profile today does not rewrite last week. The History screen is read by the owner and an admin.

When someone leaves

Removal and leaving on your own run one path, because two paths to one event eventually disagree and one of them forgets to revoke something.

All of it happens in one step, and that is the point of this lesson: access ends in one place instead of being remembered from a chat.

  • Access ends both ways

    their reach into your profiles goes, and anyone's reach into the profiles leaving with them

  • Their hold is released

    an open profile would otherwise look occupied to everyone who stayed

  • Work profiles stay

    profiles made after they joined were created in your quota and stay with the workspace

  • Library addresses stay

    a profile that walks out loses the workspace address behind it, and keeps their own

  • Unused invites are burned

    an unaccepted code to the same address would be a key back in

What this lesson does not claim

  • Roles apply to the whole workspace. Group access narrows what a person sees, not what their role may do.
  • An invite reaches an account that already exists. The letter goes out where mail is set up, and otherwise you pass the link over yourself.
  • Revoking a share takes a profile out of a colleague's app and leaves the cookies already on their disk. Revocation is not a remote wipe.
  • History pages from the newest row backwards, with no filter by person, action or date.
  • Many platforms forbid one account being worked by several people. Nothing here changes their rules or offers a way around them.

Where you can check this

Each claim above has a file behind it and a stand in the suite.

The ordinary list carries no password, a separate request hands one over, and that lands in the history
apps/server/test/proxy-secret.js
A granted group narrows the list and the direct open alike, and an empty choice means no restriction
apps/server/test/group-access.js
Removal and leaving run one path: access cut both ways, the hold released, addresses left behind
apps/server/test/team-money-seats.js
Roles are compared by rank, so a role the server does not know grants nothing
apps/server/src/common/roles/workspace-roles.ts
Someone who joins a team stays the owner of their own workspace, and seats and leaving count per workspace
apps/server/test/несколько-команд.js

Questions

Does a colleague see the password of a shared address?
Not in the list they read. It reaches them only for an address behind a profile opened to them, and the handover goes into the history.
What happens to the profiles a contractor made?
Ones created after they joined stay with the workspace that paid for them. Ones they brought in leave with them, without your library address.
Is an empty group list the safest setting?
It is the widest one. An empty choice means no restriction, so leave one group ticked when a view has to stay narrow.
Do two people need two plans?
No, a workspace has one bill. Seats come with the plan, further ones are bought a seat at a time, and an invite with no free seat is refused.
Can a teammate widen their own groups?
No, that request is refused below an admin. Otherwise the narrowing would be a suggestion rather than a rule.

Invite one colleague first

Open a single group to them and read their list from their side.