Skip to content

Access control

Access control lets you control who (users and groups) has what access (role) to which resources (canvases or folders).

Every resource, like canvas or folder, on a Canvus Connect server has a list of associated permissions. Each permission identifies a specific principal (user or group of users) and a role, such as viewer or editor.

To share canvases or folders with others, the user must have either the owner or editor role. The ability of editor role to change permissions can be enabled or disabled restricted on a per resource basis.

Access level

Each user in Canvus has an access level. This can be either regular or administrator.

  • Regular users are subject to normal access control
  • Administrator users can access all resources and can manage all features on the Canvus Connect server.

Administrator status in the web client

When a user signs in to the web client, their administrator status is re-checked against the server on every session start. If an administrator revokes a user's privileges while that user is signed in, the web client will reflect the change the next time the user opens or refreshes the application -- stale administrator UI is no longer shown after a privilege change.

Roles

Canvus specifies the following roles for each resource (canvas or folder):

  • No access the principal has no access to the resource
  • Viewer the principal can view the resource, but can not make any changes to it
  • Editor the principal can edit the resource and make changes to it, but may not delete it
  • Owner the user is the owner of the resource and can delete it

Permission propagation

Permission lists for folders propagate and are inherited by all child canvases and folders. Every time the permissions or the resource hierarchy changes, permissions propagate recursively through all nested folders. For example, if a canvas exists in a folder and that folder is then moved within another folder, the permissions of the new folder propagate to the canvas.

Permissions on a resource have priority over permissions that propagate from a parent folder. This means, if you grant All Users access to a folder, you can restrict the access of individual users in child resources.

Unified sign-in across the dashboard and web client

Canvus 26.4.0 unifies the sign-in experience between the admin dashboard and the web client. A user who signs in to one surface is automatically signed in to the other, and signing out of either surface ends the session on both.

In practice this means:

  • Single sign-in. When a user signs in to the dashboard (for example, at https://your-server/admin), the same credentials are used to start a web-client session. Users who move from administrative tasks to editing a canvas no longer see a second login screen.
  • Single sign-out. Signing out from either the dashboard or the web client tears down the session on both surfaces and invalidates the user's private token. The next request from either surface will prompt for credentials again.
  • Consistent identity. Because both surfaces share a session, changes to the signed-in user's access level or group membership take effect on the next request, without requiring users to manually sign out and back in (see also Administrator status in the web client above).

No additional configuration is required. The behaviour is enabled by default for all deployments running Canvus 26.4.0 or later.

Share links (URLs of the form https://your-server/open/<canvas-id>?share=<token>) let you grant access to a specific canvas without provisioning a user account for the recipient.

In Canvus 26.4.0, a user who opens the web client by following a share link is treated as an authenticated session for the duration of that session. The share token determines which canvas the guest can open and what role they receive on it (for example, viewer or editor). The guest does not receive a general-purpose account and cannot see other canvases or folders; their access is scoped to the resources the share link grants.

This replaces the earlier behaviour in which share-link guests were treated as anonymous and could be denied access to some routes even though they held a valid share token. Guests following a current share link now receive a consistent authenticated experience across every part of the web client.

When you revoke or expire a share link, existing guest sessions that depend on that link lose access the next time they make a request.

Multi-site deployments

In multi-site deployments -- where several Canvus servers are federated so that users can reach canvases hosted on peer servers -- permission checks now take the hosting server into account. When a user opens a canvas that is owned by a peer server, the local server resolves the owner identity in the context of that peer, rather than attempting to match it against local users.

The practical effect for administrators:

  • Users who have accounts on more than one server in a federation are recognised correctly on each server without having to duplicate local permissions.
  • Ownership and role assignments made on the hosting server are honoured when a canvas is reached from a peer.
  • Share links issued by any server in the federation continue to work when followed from any other server.

No per-server configuration is required to enable this behaviour in 26.4.0; it applies automatically to any server that is configured as part of a multi-site federation.

Administrator workflow: creating canvases and folders

When administrators (or any user with the required role) create a canvas or folder from the dashboard, the dashboard now rejects an empty name at submission time and prompts the administrator to provide one before the resource is created. This prevents accidentally-created nameless resources from appearing in permission and audit views, where they are difficult to identify and manage.