Users, Roles, and Permissions

Users, roles, and permissions

Cove is built to support more than one person using the same library. That means access needs to be deliberate instead of collapsing into one shared login with full control over everything.

The access model

Users are the people or service identities signing in.
Groups let you manage related users together.
Roles bundle reusable action permissions.
Content rules decide what those roles can see.
Share links let you expose selected content within your network without creating a full account.
API tokens let scripts or integrations authenticate without reusing a password.

These pieces are strongest when used together, not in isolation.

A practical setup order

Keep the owner account protected and use it sparingly.
Create separate user accounts for real people.
Define roles around actual responsibilities.
Add content rules when visibility should differ between people.
Use share links for narrow access within your network instead of broad logins.

Roles versus content rules

This distinction is important:

roles control what actions an account can take
content rules control which items an account can see

Someone might be allowed to browse but not edit. Someone else might be allowed to edit, but only inside a specific slice of the library. Those are different problems, and Cove treats them separately.

Share links are useful when you want to expose specific content within your network without turning a temporary need into a full new account. They are a better fit when:

the access is narrow
the access is time-limited
the person does not need normal library navigation

Internet exposure

If you expose Cove outside your local network, treat it like any self-hosted application that can access private media:

put it behind your own reverse proxy and TLS
avoid exposing administrator accounts directly
review roles and share links carefully
assume the security model is only as strong as the way you publish the service