forked from nrkno/sofie-core
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
37 additions
and
24 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
58 changes: 36 additions & 22 deletions
58
packages/documentation/docs/user-guide/features/access-levels.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,46 +1,60 @@ | ||
--- | ||
sidebar_position: 3 | ||
--- | ||
|
||
# Access Levels | ||
|
||
A variety of access levels can be set via the URL. By default, a user cannot edit settings, nor play out anything. Some of the access levels provide additional administrative pages or helpful tool tips for new users. These modes are persistent between sessions and will need to be manually disabled by replacing the _1_ with a _0_ in the URL. Below is a quick reference to the modes and what they have access to. | ||
## Permissions | ||
|
||
If user accounts are enabled \(`enableUserAccounts` in [_Sofie Core_ settings](../configuration/sofie-core-settings#settings-file)\), the access levels are set under the user settings. If no user accounts are set, the access level for a browser is set by adding `?theaccessmode=1` to the URL as described below. | ||
There are a few different access levels that users can be assigned. They are not heirarchical, you will often need to enable multiple for each user. | ||
Any client that can access sofie always has at least view-only access to the rundowns, and system status pages. | ||
|
||
The access level is persisted in browser's Local Storage. To disable, visit`?theaccessmode=0`. | ||
| Level | Summary | | ||
| :------------ | :----------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| **studio** | Grants access to operate a studio for playout of a rundown. | | ||
| **configure** | Grants access to the settings pages of Sofie, and other abilities to configure the system. | | ||
| **developer** | Grants access to some tools useful to developers. This also changes some ui behaviours to be less agressive in what is shown in the rundown view | | ||
| **testing** | Enables the page Test Tools, which contains various tools useful for testing the system during development | | ||
| **service** | Grants access to the external message status page, and some additional rundown management options that are not commonly needed | | ||
| **gateway** | Grants access to various APIs intended for use by the various gateways that connect Sofie to other systems. | | ||
|
||
| Access area | Basic Mode | Configuration Mode | Studio Mode | Admin Mode | | ||
| :--- | :--- | :--- | :--- | :--- | | ||
| **Rundowns** | View Only | View Only | Yes, playout | Yes, playout | | ||
| **Settings** | No | Yes | No | Yes | | ||
## Authentication providers | ||
|
||
There are two ways to define the access for each user, which to use depends on your security requirements. | ||
|
||
### Basic mode | ||
### Browser based | ||
|
||
Without enabling any additional modes in Sofie, the browser will have minimal access to the system. It will be able to view a rundown but, will not have the ability to manipulate it. This includes activating, deactivating, or resetting the rundown as well as taking the next part, adlib, etc. | ||
:::info | ||
|
||
### Studio mode | ||
This is a simple mode that relies on being able to trust every client that can connect to Sofie | ||
|
||
Studio Mode gives the current browser full control of the studio and all information associated to it. This includes allowing actions like activating and deactivating rundowns, taking parts, adlibbing, etc. This mode is accessed by adding a `?studio=1` to the end of the URL. | ||
::: | ||
|
||
### Configuration mode | ||
In this mode, a variety of access levels can be set via the URL. The access level is persisted in browser's Local Storage. | ||
|
||
Configuration mode gives the user full control over the Settings pages and allows full access to the system including the ability to modify _Blueprints_, _Studios_, or _Show Styles_, creating and restoring _Snapshots_, as well as modifying attached devices. | ||
By default, a user cannot edit settings, nor play out anything. Some of the access levels provide additional administrative pages or helpful tool tips for new users. These modes are persistent between sessions and will need to be manually enabled or disabled by appending a suffix to the url. | ||
Each of the modes listed in the levels table above can be used here, such as by navigating to `https://my-sofie/?studio=1` to enable studio mode, or `https://my-sofie/?studio=0` to disable studio mode. | ||
|
||
### Help Mode | ||
There are some additional url parameters that can be used to simplify the granting of permissions: | ||
|
||
Enables some tooltips that might be useful to new users. This mode is accessed by adding `?help=1` to the end of the URL. | ||
- `?help=1` will enable some tooltips that might be useful to new users. | ||
- `?admin=1` will give the user the same access as the _Configuration_ and _Studio_ modes as well as having access to a set of _Test Tools_ and a _Manual Control_ section on the Rundown page. | ||
|
||
### Admin Mode | ||
### Header based | ||
|
||
This mode will give the user the same access as the _Configuration_ and _Studio_ modes as well as having access to a set of _Test Tools_ and a _Manual Control_ section on the Rundown page. | ||
:::danger | ||
|
||
This mode is enabled when `?admin=1` is added the end of the URL. | ||
This mode is very new and could have some undiscovered holes. | ||
It is known that secrets can be leaked to all clients who can connect to Sofie, which is not desirable. | ||
|
||
### Testing Mode | ||
::: | ||
|
||
Enables the page Test Tools, which contains various tools useful for testing the system during development. This mode is enabled when `?testing=1` is added the end of the URL. | ||
In this mode, we rely on Sofie being run behind a reverse-proxy which will inform Sofie of the permissions of each connection. This allows you to use your organisations preferred auth provider, and translate that into something that Sofie can understand. | ||
To enable this mode, you need to enable the `enableHeaderAuth` property in the [settings file](../configuration/sofie-core-settings.md) | ||
|
||
### Developer Mode | ||
Sofie expects that for each DDP connection or http request, the `dnt` header will be set containing a comma separated list of the levels from the above table. If the header is not defined or is empty, the connection will have view-only access to Sofie. | ||
This header can also contain simply `admin` to grant the connection permission to everything. | ||
We are using the `dnt` header due to limitations imposed by Meteor, but intend this to become a proper header name in a future release. | ||
|
||
This mode will enable the browsers default right click menu to appear and can be accessed by adding `?develop=1` to the URL. It will also reveal the Manual Control section on the Rundown page. | ||
When in this mode, you should make sure that Sofie can only be accessed through the reverse proxy, and that the reverse-proxy will always override any value sent by a client. | ||
Because the value is defined in the http headers, it is not possible to revoke permissions for a user who currently has the ui open. If this is necessary to do, you can force the connection to be dropped by the reverse-proxy. |