centersl/open-webui-docs
1
0
Fork 0
mirror of https://github.com/open-webui/docs.git synced 2026-03-26 13:18:42 +07:00
Code Issues Packages Projects Releases Wiki Activity

ACL - 0.8.0

Browse Source
This commit is contained in:
DrMelone
2026-02-09 22:11:43 +01:00
parent 854134e39f
commit eb7e08d914
7 changed files with 77 additions and 75 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/features/rbac/groups.md
View File

@@ -64,29 +64,23 @@ When editing a group, you can toggle specific permissions.
## Resource Access (RBAC)
You can restrict access to specific objects (like a proprietary Model or sensitive Knowledge Base) using Groups.
You can restrict access to specific objects (like a proprietary Model or sensitive Knowledge Base) using Groups or individual user grants.
1. **Tag the Resource**: When creating/editing a Model or Knowledge Base, set its visibility to **Private** or **Restricted**.
2. **Grant Access**: Select the specific **Groups** (or individual users) that should have "Read" or "Write" access.
2. **Grant Access**: Select the specific **Groups** or **individual users** that should have "Read" or "Write" access. The redesigned access control UI makes it easy to add multiple groups or users at once.
:::tip Knowledge Scoping for Models
Beyond visibility, knowledge access is also scoped by model configuration. When a model has **attached knowledge bases**, it can only access those specific KBs (not all user-accessible KBs). See [Knowledge Scoping with Native Function Calling](/features/workspace/knowledge#knowledge-scoping-with-native-function-calling) for details.
:::
### Access Control Object
At a deeper level, resources store an access control list (ACL) looking like this:
### Access Grant System
At a deeper level, resource access is managed through normalized **access grants** stored in the database. Each grant specifies:
* **Resource**: The type and ID of the resource (e.g., a specific model or knowledge base).
* **Principal**: Who receives access — either a **group** or an **individual user**.
* **Permission**: The level of access — `read` or `write`.
For example, granting the "Marketing" group read access and a specific editor user write access to a model would create two separate grant entries. Public access is represented by a user grant with a wildcard (`*`) principal.
```json
{
"read": {
"group_ids": ["marketing-team-id", "admins-id"],
"user_ids": []
},
"write": {
"group_ids": ["admins-id"],
"user_ids": ["editor-user-id"]
}
}
```
* **Read**: Users can view and use the resource.
* **Write**: Users can update or delete the resource.

4
docs/features/rbac/index.mdx
View File

@@ -7,7 +7,7 @@ Open WebUI implements a flexible and secure **Role-Based Access Control (RBAC)**
1. [**Roles**](./roles.md): The high-level user type (Admin, User, Pending). This defines the baseline trust level.
2. [**Permissions**](./permissions.md): Granular feature flags (e.g., "Can Delete Chats", "Can Use Web Search").
3. [**Groups**](./groups.md): The mechanism for organizing users, granting additional permissions, and managing shared access to resources (ACLs).
3. [**Groups**](./groups.md): The mechanism for organizing users, granting additional permissions, and managing shared access to resources (ACLs). Resources can also be shared directly to individual users.
:::info Key Concept: Additive Permissions
The security model is **Additive**. Users start with their default rights, and Group memberships **add** capabilities. A user effectively has the *union* of all rights granted by their Roles and Groups.
@@ -27,4 +27,4 @@ The security model is **Additive**. Users start with their default rights, and G
* [‍🔐 **Groups**](./groups.md)
* Learn how to structure teams and projects.
* **Strategy**: Distinguish between "Permission Groups" (for rights) and "Sharing Groups" (for access).
* Manage Access Control Lists (ACLs) for private Models and Knowledge.
* Manage Access Control Lists (ACLs) for private Models and Knowledge — share with groups or individual users.

2
docs/features/workspace/models.md
View File

@@ -30,7 +30,7 @@ Both actions lead to the same Model Builder interface, where you can configure t
- **Tags**: Add tags to organize models in the selector dropdown.
- **Visibility & Groups**:
- **Private**: Restricts access to specific users or groups.
- **Groups Selector**: Use the dropdown to grant access to specific teams (e.g., "Admins", "Developers") without making the model public to everyone.
- **Access Control Selector**: Use the access control panel to grant access to specific groups (e.g., "Admins", "Developers") or individual users without making the model public to everyone. The redesigned interface makes it easy to add multiple groups and users at once.
### System Prompt & Dynamic Variables

2
docs/getting-started/env-configuration.mdx
View File

@@ -12,7 +12,7 @@ As new variables are introduced, this page will be updated to reflect the growin
:::info
This page is up-to-date with Open WebUI release version [v0.7.1](https://github.com/open-webui/open-webui/releases/tag/v0.7.1), but is still a work in progress to later include more accurate descriptions, listing out options available for environment variables, defaults, and improving descriptions.
This page is up-to-date with Open WebUI release version [v0.8.0](https://github.com/open-webui/open-webui/releases/tag/v0.8.0), but is still a work in progress to later include more accurate descriptions, listing out options available for environment variables, defaults, and improving descriptions.
:::

2
docs/getting-started/quick-start/tab-docker/ManualDocker.md
View File

@@ -23,7 +23,7 @@ docker pull ghcr.io/open-webui/open-webui:main-slim
You can also pull a specific Open WebUI release version directly by using a versioned image tag. This is recommended for production environments to ensure stable and reproducible deployments.
```bash
docker pull ghcr.io/open-webui/open-webui:v0.7.0
docker pull ghcr.io/open-webui/open-webui:v0.8.0
```
## Step 2: Run the Container

6
docs/intro.mdx
View File

@@ -99,9 +99,9 @@ ghcr.io/open-webui/open-webui:<RELEASE_VERSION>-<TYPE>
Examples (pinned versions for illustration purposes only):
```
ghcr.io/open-webui/open-webui:v0.7.0
ghcr.io/open-webui/open-webui:v0.7.0-ollama
ghcr.io/open-webui/open-webui:v0.7.0-cuda
ghcr.io/open-webui/open-webui:v0.8.0
ghcr.io/open-webui/open-webui:v0.8.0-ollama
ghcr.io/open-webui/open-webui:v0.8.0-cuda
```
### Using the Dev Branch 🌙

110
docs/tutorials/tips/sqlite-database.md
View File

@@ -10,7 +10,7 @@ This tutorial is a community contribution and is not supported by the Open WebUI
:::
> [!WARNING]
> This documentation was created/updated based on version 0.7.0 and updated for recent migrations.
> This documentation was created/updated based on version 0.8.0 and updated for recent migrations.
## Open-WebUI Internal SQLite Database
@@ -54,35 +54,36 @@ Here is a complete list of tables in Open-WebUI's SQLite database. The tables ar
| **No.** | **Table Name** | **Description** |
| ------- | ---------------- | ------------------------------------------------------------ |
| 01 | auth | Stores user authentication credentials and login information |
| 02 | channel | Manages chat channels and their configurations |
| 03 | channel_file | Links files to channels and messages |
| 04 | channel_member | Tracks user membership and permissions within channels |
| 05 | chat | Stores chat sessions and their metadata |
| 06 | chat_file | Links files to chats and messages |
| 07 | chatidtag | Maps relationships between chats and their associated tags |
| 08 | config | Maintains system-wide configuration settings |
| 09 | document | Stores documents and their metadata for knowledge management |
| 10 | feedback | Captures user feedback and ratings |
| 11 | file | Manages uploaded files and their metadata |
| 12 | folder | Organizes files and content into hierarchical structures |
| 13 | function | Stores custom functions and their configurations |
| 14 | group | Manages user groups and their permissions |
| 15 | group_member | Tracks user membership within groups |
| 16 | knowledge | Stores knowledge base entries and related information |
| 17 | knowledge_file | Links files to knowledge bases |
| 18 | memory | Maintains chat history and context memory |
| 19 | message | Stores individual chat messages and their content |
| 20 | message_reaction | Records user reactions (emojis/responses) to messages |
| 21 | migrate_history | Tracks database schema version and migration records |
| 22 | model | Manages AI model configurations and settings |
| 23 | note | Stores user-created notes and annotations |
| 24 | oauth_session | Manages active OAuth sessions for users |
| 25 | prompt | Stores templates and configurations for AI prompts |
| 26 | prompt_history | Tracks version history and snapshots for prompts |
| 27 | tag | Manages tags/labels for content categorization |
| 28 | tool | Stores configurations for system tools and integrations |
| 29 | user | Maintains user profiles and account information |
| 01 | access_grant | Stores normalized access control grants for all resources |
| 02 | auth | Stores user authentication credentials and login information |
| 03 | channel | Manages chat channels and their configurations |
| 04 | channel_file | Links files to channels and messages |
| 05 | channel_member | Tracks user membership and permissions within channels |
| 06 | chat | Stores chat sessions and their metadata |
| 07 | chat_file | Links files to chats and messages |
| 08 | chatidtag | Maps relationships between chats and their associated tags |
| 09 | config | Maintains system-wide configuration settings |
| 10 | document | Stores documents and their metadata for knowledge management |
| 11 | feedback | Captures user feedback and ratings |
| 12 | file | Manages uploaded files and their metadata |
| 13 | folder | Organizes files and content into hierarchical structures |
| 14 | function | Stores custom functions and their configurations |
| 15 | group | Manages user groups and their permissions |
| 16 | group_member | Tracks user membership within groups |
| 17 | knowledge | Stores knowledge base entries and related information |
| 18 | knowledge_file | Links files to knowledge bases |
| 19 | memory | Maintains chat history and context memory |
| 20 | message | Stores individual chat messages and their content |
| 21 | message_reaction | Records user reactions (emojis/responses) to messages |
| 22 | migrate_history | Tracks database schema version and migration records |
| 23 | model | Manages AI model configurations and settings |
| 24 | note | Stores user-created notes and annotations |
| 25 | oauth_session | Manages active OAuth sessions for users |
| 26 | prompt | Stores templates and configurations for AI prompts |
| 27 | prompt_history | Tracks version history and snapshots for prompts |
| 28 | tag | Manages tags/labels for content categorization |
| 29 | tool | Stores configurations for system tools and integrations |
| 30 | user | Maintains user profiles and account information |
Note: there are two additional tables in Open-WebUI's SQLite database that are not related to Open-WebUI's core functionality, that have been excluded:
@@ -91,6 +92,26 @@ Note: there are two additional tables in Open-WebUI's SQLite database that are n
Now that we have all the tables, let's understand the structure of each table.
## Access Grant Table
| **Column Name** | **Data Type** | **Constraints** | **Description** |
| --------------- | ------------- | ----------------------- | ------------------------------------------------------ |
| id | Integer | PRIMARY KEY, AUTOINCREMENT | Unique identifier |
| resource_type | Text | NOT NULL | Type of resource (e.g., `model`, `knowledge`, `tool`) |
| resource_id | Text | NOT NULL | ID of the specific resource |
| principal_type | Text | NOT NULL | Type of grantee: `user` or `group` |
| principal_id | Text | NOT NULL | ID of the user or group (or `*` for public) |
| permission | Text | NOT NULL | Permission level: `read` or `write` |
| created_at | BigInteger | nullable | Grant creation timestamp |
Things to know about the access_grant table:
- Unique constraint on (`resource_type`, `resource_id`, `principal_type`, `principal_id`, `permission`) to prevent duplicate grants
- Indexed on (`resource_type`, `resource_id`) and (`principal_type`, `principal_id`) for efficient lookups
- Replaces the former `access_control` JSON column that was previously embedded in each resource table
- `principal_type` of `user` with `principal_id` of `*` represents public (open) access
- Supports both group-level and individual user-level access grants
## Auth Table
| **Column Name** | **Data Type** | **Constraints** | **Description** |
@@ -116,7 +137,7 @@ Things to know about the auth table:
| description | Text | nullable | Channel description |
| data | JSON | nullable | Flexible data storage |
| meta | JSON | nullable | Channel metadata |
| access_control | JSON | nullable | Permission settings |
| created_at | BigInteger | - | Creation timestamp (nanoseconds) |
| updated_at | BigInteger | - | Last update timestamp (nanoseconds) |
@@ -237,7 +258,7 @@ Things to know about the chat_file table:
| path | Text | nullable | File system path |
| data | JSON | nullable | File-related data |
| meta | JSON | nullable | File metadata |
| access_control | JSON | nullable | Permission settings |
| created_at | BigInteger | - | Creation timestamp |
| updated_at | BigInteger | - | Last update timestamp |
@@ -335,7 +356,7 @@ Things to know about the group_member table:
| description | Text | - | Knowledge base description |
| data | JSON | nullable | Knowledge base content |
| meta | JSON | nullable | Additional metadata |
| access_control | JSON | nullable | Access control rules |
| created_at | BigInteger | - | Creation timestamp |
| updated_at | BigInteger | - | Last update timestamp |
@@ -356,20 +377,7 @@ Things to know about the knowledge_file table:
- Foreign key relationships with CASCADE delete
- Indexed on `knowledge_id`, `file_id`, and `user_id` for performance
The `access_control` fields expected structure:
```python
{
"read": {
"group_ids": ["group_id1", "group_id2"],
"user_ids": ["user_id1", "user_id2"]
},
"write": {
"group_ids": ["group_id1", "group_id2"],
"user_ids": ["user_id1", "user_id2"]
}
}
```
Access control for resources (models, knowledge bases, tools, prompts, notes, files, channels) is managed through the `access_grant` table rather than embedded JSON. Each grant entry specifies a resource, a principal (user or group), and a permission level (read or write). See the [Access Grant Table](#access-grant-table) section above for details.
## Memory Table
@@ -415,7 +423,7 @@ The `access_control` fields expected structure:
| name | Text | - | Display name |
| params | JSON | - | Model parameters |
| meta | JSON | - | Model metadata |
| access_control | JSON | nullable | Access permissions |
| is_active | Boolean | default=True | Active status |
| created_at | BigInteger | - | Creation timestamp |
| updated_at | BigInteger | - | Last update timestamp |
@@ -429,7 +437,7 @@ The `access_control` fields expected structure:
| title | Text | nullable | Note title |
| data | JSON | nullable | Note content and data |
| meta | JSON | nullable | Note metadata |
| access_control | JSON | nullable | Permission settings |
| created_at | BigInteger | nullable | Creation timestamp |
| updated_at | BigInteger | nullable | Last update timestamp |
@@ -456,7 +464,7 @@ The `access_control` fields expected structure:
| content | Text | NOT NULL | Prompt content/template |
| data | JSON | nullable | Additional prompt data |
| meta | JSON | nullable | Prompt metadata |
| access_control | JSON | nullable | Permission settings |
| is_active | Boolean | default=True | Active status |
| version_id | Text | nullable | Current version identifier |
| tags | JSON | nullable | Associated tags |
@@ -499,7 +507,7 @@ Things to know about the tag table:
| specs | JSON | - | Tool specifications |
| meta | JSON | - | Tool metadata |
| valves | JSON | - | Tool control settings |
| access_control | JSON | nullable | Access permissions |
| created_at | BigInteger | - | Creation timestamp |
| updated_at | BigInteger | - | Last update timestamp |