<commit_before>### OpenDataSoft's security model

OpenDataSoft provides a full stack security layer with users, groups and roles management. Using this security layer, you can restrict the access to your dataset's catalog as well as to the content of a single dataset.

An OpenDataSoft domain can be kept private or can be made public. When set to private, a domain can only be accessed by users defined in the access list of the domain. When set to public, a domain can be accessed by anyone (this however does not mean that any user will be able to browse the entire domain catalog).

The domain access list is made of users and groups of users to which permissions are attached. Two different set of permissions can be defined: permissions related to regular users and permissions related to admin users (those guys with super powers). The permissions make it possible to give the right to read the dataset catalog, create and publish new datasets or even visualize and modify any dataset of the domain.

Then, at the dataset level, it is possible to even further refine the security model by giving specific access to users or groups to either view or modify the dataset. It is also possible to define advanced filters so that a given user will only see some fields and/or a subset of the dataset records.

### Configuring your domain's security policy

#### Domain access and default security policy

![Security Model](security-model.jpg)

Check the option **allow anonymous access** if you want to let people access your domain without having to log in. Anonymous users will only be able to access non restricted datasets. This makes it possible to mix on the single domain a public facing catalog and a private catalog that can only be accessed by authorized users.

Datasets access can be set to be *restricted* or *not restricted*. A *restricted* dataset can only be accessed by authorized users (users who are in the access list of the dataset, see below). Check the option **restrict new datasets by default** if you want newly created datasets to be accessed only by authorized users.

The **landing page for anonymous users** can be set to any content page created on the domain. It makes it possible to host a splash screen or to disclose content to anonymous users from a private domain.

This section also allows you to define the **default permissions for new users** (see below for a detailed description of users permissions).

#### Domain access list

![Security Users](security-users.jpg)

The domain access list are made of users and groups. Users' scope is platform wide (this means that a user can be associated with more than one domain) while groups' scope is domain wide (groups are not shared among domains).

The real permissions of a user are the union of the user's own permissions and of the permissions of the groups the user belongs to. This means that if a user does not have administrative rights set while they belong to a group which has administrative rights, the user will effectively be given administrative rights.

There are two categories of **permissions**: standard permissions and administative permissions. Permissions can be attributed to users and groups.

* Standard permissions
    * The user may create new datasets and edit them
    * The user may publish their datasets
    * The user may manage the security settings of their datasets<commit_msg>allow instead of give the right to<commit_after>### OpenDataSoft's security model

OpenDataSoft provides a full stack security layer with users, groups and roles management. Using this security layer, you can restrict the access to your dataset's catalog as well as to the content of a single dataset.

An OpenDataSoft domain can be kept private or can be made public. When set to private, a domain can only be accessed by users defined in the access list of the domain. When set to public, a domain can be accessed by anyone (this however does not mean that any user will be able to browse the entire domain catalog).

The domain access list is made of users and groups of users to which permissions are attached. Two different set of permissions can be defined: permissions related to regular users and permissions related to admin users (those guys with super powers). The permissions make it possible to allow users to read the dataset catalog, create and publish new datasets or even visualize and modify any dataset of the domain.

Then, at the dataset level, it is possible to even further refine the security model by giving specific access to users or groups to either view or modify the dataset. It is also possible to define advanced filters so that a given user will only see some fields and/or a subset of the dataset records.

### Configuring your domain's security policy

#### Domain access and default security policy

![Security Model](security-model.jpg)

Check the option **allow anonymous access** if you want to let people access your domain without having to log in. Anonymous users will only be able to access non restricted datasets. This makes it possible to mix on the single domain a public facing catalog and a private catalog that can only be accessed by authorized users.

Datasets access can be set to be *restricted* or *not restricted*. A *restricted* dataset can only be accessed by authorized users (users who are in the access list of the dataset, see below). Check the option **restrict new datasets by default** if you want newly created datasets to be accessed only by authorized users.

The **landing page for anonymous users** can be set to any content page created on the domain. It makes it possible to host a splash screen or to disclose content to anonymous users from a private domain.

This section also allows you to define the **default permissions for new users** (see below for a detailed description of users permissions).

#### Domain access list

![Security Users](security-users.jpg)

The domain access list are made of users and groups. Users' scope is platform wide (this means that a user can be associated with more than one domain) while groups' scope is domain wide (groups are not shared among domains).

The real permissions of a user are the union of the user's own permissions and of the permissions of the groups the user belongs to. This means that if a user does not have administrative rights set while they belong to a group which has administrative rights, the user will effectively be given administrative rights.

There are two categories of **permissions**: standard permissions and administative permissions. Permissions can be attributed to users and groups.

* Standard permissions
    * The user may create new datasets and edit them
    * The user may publish their datasets
    * The user may manage the security settings of their datasets
{'fraction_non_alphanumeric': 0.034007622398123716, 'fraction_numerical': 0.0, 'mean_word_length': 4.484726688102894, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '933130', 'n_tokens_mistral': 1448, 'n_tokens_neox': 1413, 'n_words': 1112}