This is an automated email from the ASF dual-hosted git repository.
morningman pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new fbd686f340a [opt](auth) format authentication doc (#2975)
fbd686f340a is described below
commit fbd686f340ab49cac26dbcb3afdfcd0ac9cca35e
Author: Mingyu Chen (Rayner) <[email protected]>
AuthorDate: Tue Oct 14 21:45:07 2025 +0800
[opt](auth) format authentication doc (#2975)
## Versions
- [x] dev
- [x] 3.0
- [x] 2.1
- [ ] 2.0
## Languages
- [x] Chinese
- [x] English
## Docs Checklist
- [ ] Checked by AI
- [ ] Test Cases Built
---
.github/PULL_REQUEST_TEMPLATE.md | 2 +-
docs/admin-manual/auth/authentication/internal.md | 175 +++++++++++++--------
.../admin-manual/auth/authentication/internal.md | 143 ++++++++++++-----
.../admin-manual/auth/authentication/internal.md | 143 ++++++++++++-----
.../admin-manual/auth/authentication/internal.md | 143 ++++++++++++-----
.../admin-manual/auth/authentication/internal.md | 175 +++++++++++++--------
.../admin-manual/auth/authentication/internal.md | 175 +++++++++++++--------
7 files changed, 634 insertions(+), 322 deletions(-)
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 9b90f1a4cd8..e671fd341fb 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,7 +1,7 @@
## Versions
- [ ] dev
-- [ ] 3.0
+- [ ] 3.x
- [ ] 2.1
- [ ] 2.0
diff --git a/docs/admin-manual/auth/authentication/internal.md
b/docs/admin-manual/auth/authentication/internal.md
index b720e9b2bf3..d9a69c56974 100644
--- a/docs/admin-manual/auth/authentication/internal.md
+++ b/docs/admin-manual/auth/authentication/internal.md
@@ -6,97 +6,144 @@
---
## Key Concepts
+### Users
-### User
-In Doris, a `user_identity` uniquely identifies a user. `user_identity`
consists of two parts: `user_name` and `host`, where `user_name` is the
username. `host` identifies the host address from which the user connects. The
`host` part can use `%` for fuzzy matching. If `host` is not specified, it
defaults to `%`, meaning the user can connect to Doris from any host.
+In Doris, a user_identity uniquely identifies a user. user_identity consists
of two parts: user_name and host, where username is the user name. host
identifies the host address where the user client connection is located. The
host part can use % for fuzzy matching. If host is not specified, it defaults
to '%', which means the user can connect to Doris from any host.
#### User Attributes
-User attributes are directly attached to `user_name`, not `user_identity`,
meaning `user@'192.%'` and `user@['domain']` share the same set of user
attributes. These attributes belong to the user, not `user@'192.%'` or
`user@['domain']`.
-User attributes include, but are not limited to: maximum number of user
connections, import cluster configuration, etc.
+User attributes are directly attached to user_name, not user_identity. This
means user@'192.%' and user@['domain'] both have the same set of user
attributes. These attributes belong to user, not to user@'192.%' or
user@['domain'].
+
+User attributes include but are not limited to: maximum user connections,
import cluster configuration, etc.
#### Built-in Users
-Built-in users are users created by default in Doris and have certain
permissions by default, including `root` and `admin`. Initial passwords are
empty and can be changed after the frontend starts using password modification
commands. Default users cannot be deleted.
-- `root@'%'`: Root user, allowed to log in from any node, role is operator.
-- `admin@'%'`: Admin user, allowed to log in from any node, role is admin.
+
+Built-in users are users created by default in Doris and have certain default
permissions, including root and admin. The initial passwords are empty. After
FE starts, you can modify them using the password change command. Built-in
users cannot be deleted.
+
+- root@'%': root user, allowed to log in from any node, with operator role.
+- admin@'%': admin user, allowed to log in from any node, with admin role.
### Password
-Credentials for user login, set by the administrator when creating the user,
can also be changed by the user after creation.
-#### Password Policy
-Doris supports the following password policies to help users manage passwords
better.
+User login credentials, set by administrators when creating users, or can be
changed by users themselves after creation.
+
+#### Password Policies
+
+Doris supports the following password policies to help users better manage
passwords.
+
- `PASSWORD_HISTORY`
- Whether the current user is allowed to use historical passwords when
resetting their password. For example, `PASSWORD_HISTORY 10` means that the
past 10 passwords cannot be reused as the new password. If set to
`PASSWORD_HISTORY DEFAULT`, the value of the global variable `password_history`
will be used. 0 means this feature is not enabled. The default is 0.
- Example:
- - Set global variable: `SET GLOBAL password_history = 10`
- - Set for user: `ALTER USER user1@'ip' PASSWORD_HISTORY 10`
+
+ Whether to allow the current user to use historical passwords when resetting
passwords. For example, `PASSWORD_HISTORY` 10 means prohibiting the use of the
last 10 passwords as new passwords. If set to `PASSWORD_HISTORY DEFAULT`, it
will use the value in the global variable `password_history`. 0 means this
feature is disabled. Default is 0.
+
+ Examples:
+
+ - Set global variable: `SET GLOBAL password_history = 10`
+ - Set for user: `ALTER USER user1@'ip' PASSWORD_HISTORY 10`
+
- `PASSWORD_EXPIRE`
- Set the password expiration time for the current user. For example,
`PASSWORD_EXPIRE INTERVAL 10 DAY` means the password will expire in 10 days.
`PASSWORD_EXPIRE NEVER` means the password will never expire. If set to
`PASSWORD_EXPIRE DEFAULT`, the value of the global variable
`default_password_lifetime` will be used (in days). The default is `NEVER` (or
0), meaning the password will not expire.
- Example:
- - Set global variable: `SET GLOBAL default_password_lifetime = 1`
- - Set for user: `ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+
+ Set the expiration time for the current user's password. For example,
`PASSWORD_EXPIRE INTERVAL 10 DAY` means the password will expire in 10 days.
`PASSWORD_EXPIRE NEVER` means the password never expires. If set to
`PASSWORD_EXPIRE DEFAULT`, it will use the value in the global variable
`default_password_lifetime` (in days). Default is NEVER (or 0), meaning it will
not expire.
+
+ Examples:
+
+ - Set global variable: `SET GLOBAL default_password_lifetime = 1`
+ - Set for user: `ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+
- `FAILED_LOGIN_ATTEMPTS` and `PASSWORD_LOCK_TIME`
- Set the number of incorrect password attempts before the account is locked
and the lock time. For example, `FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1
DAY` means the account will be locked for one day after 3 incorrect login
attempts. Administrators can unlock locked accounts using the `ALTER USER`
statement.
- Example:
- - Set for user: `ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY`
+
+ Set that when the current user logs in with wrong password n times, the
account will be locked and set a lock time. For example, `FAILED_LOGIN_ATTEMPTS
3 PASSWORD_LOCK_TIME 1 DAY` means if there are 3 wrong logins, the account will
be locked for one day. Administrators can actively unlock locked accounts
through ALTER USER statements.
+
+ Examples:
+
+ - Set for user: `ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY`
+
- Password Strength
- Controlled by the global variable `validate_password_policy`. The default is
`NONE/0`, meaning no password strength check. If set to `STRONG/2`, the
password must contain at least 3 of the following: "uppercase letters",
"lowercase letters", "numbers", and "special characters", and the length must
be at least 8.
- Example:
+
+ This feature is controlled by the global variable
`validate_password_policy`. Default is NONE/0, meaning password strength is not
checked. If set to STRONG/2, the password must contain 3 of the following:
"uppercase letters", "lowercase letters", "numbers", and "special characters",
and the length must be greater than or equal to 8.
+
+ Examples:
+
- `SET validate_password_policy=STRONG`
+After setting the above policies, you can view them with the following command:
+
+```sql
+SHOW PROC "/auth/'<user>'@'<host>'";
+```
+
+Note that you need to wrap the user and host parts with single quotes
separately. For example:
+
+```
+SHOW PROC "/auth/'root'@'%'";
+SHOW PROC "/auth/'user1'@'127.0.0.1'";
+```
+
## Authentication Mechanism
-1. Client Authentication Information Sending: The client packages user
information (such as username, password, database, etc.) and sends it to the
Doris server. This information is used to prove the client's identity and
request access to the database.
-2. Server Authentication: After receiving the client's authentication
information, Doris verifies it. If the username, password, and client IP are
correct, and the user has permission to access the selected database,
authentication is successful, and Doris maps the user entity to the system's
user identity. Otherwise, authentication fails, and an error message is
returned to the client.
-## Whitelist and Blacklist
-Doris itself does not support a blacklist, only a whitelist function, but we
can simulate a blacklist in some ways. Suppose a user named `user@'192.%'` is
created, allowing users from 192.* to log in. If you want to prohibit users
from 192.168.10.1 from logging in, you can create another user
`cmy@'192.168.10.1'` and set a new password. Since 192.168.10.1 has a higher
priority than 192.%, users from 192.168.10.1 will no longer be able to log in
using the old password.
+1. Client authentication information sending: The client packages and sends
user information (such as username, password, database, etc.) to the Doris
server. This information is used to prove the client's identity and request
access to the database.
+
+2. Server authentication: After Doris receives the client's authentication
information, it performs verification. If the username, password, and client IP
are correct, and the user has permission to access the selected database,
authentication succeeds, and Doris will map the user individual to the User
Identity in the system. Otherwise, authentication fails and returns the
corresponding error message to the client.
+
+## Blacklist and Whitelist
+
+Doris itself does not support blacklists, only whitelist functionality, but we
can simulate blacklists in certain ways. Suppose we first created a user named
`user@'192.%'`, indicating that users from `192.*` are allowed to log in. If we
want to prohibit users from `192.168.10.1` from logging in, we can create
another user `cmy@'192.168.10.1'` and set a new password. Because
`192.168.10.1` has higher priority than `192.%`, users from `192.168.10.1` will
no longer be able to log in using [...]
## Related Commands
-- Create User: [CREATE
USER](../../../sql-manual/sql-statements/account-management/CREATE-USER)
-- View User: [SHOW ALL
GRANTS](../../../sql-manual/sql-statements/account-management/SHOW-GRANTS)
-- Modify User: [ALTER
USER](../../../sql-manual/sql-statements/account-management/ALTER-USER)
-- Change Password: [SET
PASSWORD](../../../sql-manual/sql-statements/account-management/SET-PASSWORD)
-- Delete User: [DROP
USER](../../../sql-manual/sql-statements/account-management/DROP-USER)
-- Set User Attributes: [SET
PROPERTY](../../../sql-manual/sql-statements/account-management/SET-PROPERTY)
-- View User Attributes: [SHOW
PROPERTY](../../../sql-manual/sql-statements/account-management/SHOW-PROPERTY)
-
-## Other Explanations
- 1. User Identity Priority Selection Issue During Login
-
- As introduced above, `user_identity` consists of `user_name` and `host`,
but when logging in, the user only needs to enter `user_name`, so Doris
determines based on the client's IP which `user_identity` to use for login.
-
- If only one `user_identity` can be matched based on the client's IP, it
will be used for login without any issues. However, if multiple `user_identity`
can be matched, there will be a priority issue.
- 1. Priority between domain name and IP:
- Suppose the following users are created:
- ```sql
- CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
- CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
- ```
- `domain1` is resolved to two IPs: `ip1` and `ip2`.
-
- In terms of priority, IP takes precedence over domain name.
Therefore, when user `user1` attempts to log in to Doris from `ip1` using
password `'12345'`, the login will be rejected.
- 2. Priority between specific IP and range IP:
- Suppose the following users are created:
+
+- Create user: [CREATE
USER](../../../sql-manual/sql-statements/account-management/CREATE-USER)
+- View users: [SHOW ALL
GRANTS](../../../sql-manual/sql-statements/account-management/SHOW-GRANTS)
+- Modify user: [ALTER
USER](../../../sql-manual/sql-statements/account-management/ALTER-USER)
+- Change password: [SET
PASSWORD](../../../sql-manual/sql-statements/account-management/SET-PASSWORD)
+- Delete user: [DROP
USER](../../../sql-manual/sql-statements/account-management/DROP-USER)
+- Set user attributes: [SET
PROPERTY](../../../sql-manual/sql-statements/account-management/SET-PROPERTY)
+- View user attributes: [SHOW
PROPERTY](../../../sql-manual/sql-statements/account-management/SHOW-PROPERTY)
+
+## Other Notes
+
+1. Priority selection of user_identity during login
+
+ As mentioned above, `user_identity` consists of `user_name` and `host`,
but when users log in, they only need to input `user_name`, so Doris matches
the corresponding `host` based on the client's IP to determine which
`user_identity` to use for login.
+
+ If only one `user_identity` can be matched based on the client IP, then
this `user_identity` will undoubtedly be matched. However, when multiple
`user_identity` can be matched, there will be the following priority issues.
+
+ 1. Priority between domain and IP:
+
+ Suppose the following users were created:
+
```sql
- CREATE USER user1@'%' IDENTIFIED BY "12345";
- CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
+ CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
```
- In terms of priority, `'192.%'` takes precedence over `'%'`.
Therefore, when user `user1` attempts to log in to Doris from `192.168.1.1`
using password `'12345'`, the login will be rejected.
- 2. Forgotten Password
+ domain1 is resolved to two IPs: ip1 and ip2.
+
+ In terms of priority, IP takes precedence over domain, so when user
user1 tries to log in to Doris from ip1 using password '12345', it will be
rejected.
+
+ 2. Priority between specific IP and IP range:
+
+ Suppose the following users were created:
+
+ ```sql
+ CREATE USER user1@'%' IDENTIFIED BY "12345";
+ CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ ```
+
+ In terms of priority, '192.%' takes precedence over '%', so when user
user1 tries to log in to Doris from 192.168.1.1 using password '12345', it will
be rejected.
+
+2. Forgot password
- If you forget your password and cannot log in to Doris, you can add the
`skip_localhost_auth_check=true` parameter to the FE's configuration file and
restart the FE. This will allow you to log in to Doris from the FE machine
without a password using the `root` user.
+ If you forget your password and cannot log in to Doris, you can add the
skip_localhost_auth_check=true parameter in the FE config file and restart FE,
so you can log in to Doris as root on the FE local machine without a password.
- After logging in, you can use the `SET PASSWORD` command to reset your
password.
+ After logging in, you can reset the password using the SET PASSWORD
command.
- 3. Any user cannot reset the password of the `root` user, except for the
`root` user itself.
+3. No user can reset the root user's password except the root user itself.
- 4. `current_user()` and `user()`
+4. `current_user()` and `user()`
- Users can use `SELECT current_user()` and `SELECT user()` to view
`current_user` and `user`, respectively. `current_user` indicates the identity
used by the current user to pass the authentication system, while `user` is the
actual User Identity of the current user.
+ Users can view `current_user` and `user` through `SELECT current_user()`
and `SELECT user()` respectively. `current_user` represents the identity
through which the current user passed the authentication system, while `user`
is the user's actual User Identity.
- For example:
+ Example:
- Suppose `user1@'192.%'` is created, and then a user named `user1` logs
in to the system from `192.168.10.1`. At this time, `current_user` is
`user1@'192.%'`, and `user` is `user1@'192.168.10.1'`.
+ Suppose we created the user `user1@'192.%'`, then user `user1` from
`192.168.10.1` logged into the system. In this case, `current_user` would be
`user1@'192.%'`, while `user` would be `user1@'192.168.10.1'`.
- All permissions are granted to a specific `current_user`, and the
actual user has all the permissions of the corresponding `current_user`.
+ All permissions are granted to a specific `current_user`, and the actual
user has all the permissions of the corresponding `current_user`.
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/auth/authentication/internal.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/auth/authentication/internal.md
index c835ecbc3b9..d1eb716fc99 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/auth/authentication/internal.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/auth/authentication/internal.md
@@ -7,45 +7,89 @@
## 关键概念
### 用户
+
在 Doris 中，一个 user_identity 唯一标识一个用户。user_identity 由两部分组成，user_name 和 host，其中
username 为用户名。host 标识用户端连接所在的主机地址。host 部分可以使用 % 进行模糊匹配。如果不指定 host，默认为
'%'，即表示该用户可以从任意 host 连接到 Doris。
+
#### 用户属性
+
用户属性直接附属于 user_name，而不是 user_identity，即 user@'192.%' 和 user@['domain']
都拥有同一组用户属性。该属性属于 user，而不是 user@'192.%' 或 user@['domain']。
用户属性包括但不限于：用户最大连接数、导入集群配置等等。
+
#### 内置用户
+
内置用户是 Doris 默认创建的用户，并默认拥有一定的权限，包括 root 和 admin。初始密码都为空，fe
启动后，可以通过修改密码命令进行修改。不支持删除默认用户。
+
- root@'%'：root 用户，允许从任意节点登录，角色为 operator。
- admin@'%'：admin 用户，允许从任意节点登录，角色为 admin。
### 密码
+
用户登录的凭据，管理员创建用户时设置，也可以创建后由用户自己更改密码。
#### 密码策略
+
Doris 支持以下密码策略，可以帮助用户更好的进行密码管理。
-- PASSWORD_HISTORY
- 是否允许当前用户重置密码时使用历史密码。如 PASSWORD_HISTORY 10 表示禁止使用过去 10 次设置过的密码为新密码。如果设置为
PASSWORD_HISTORY DEFAULT，则会使用全局变量 password_history 中的值。0 表示不启用这个功能。默认为 0。
+
+- `PASSWORD_HISTORY`
+
+ 是否允许当前用户重置密码时使用历史密码。如 `PASSWORD_HISTORY` 10 表示禁止使用过去 10 次设置过的密码为新密码。如果设置为
`PASSWORD_HISTORY DEFAULT`，则会使用全局变量 `password_history` 中的值。0 表示不启用这个功能。默认为 0。
+
示例：
- - 设置全局变量：SET GLOBAL password_history = 10
- - 为用户设置：ALTER USER user1@'ip' PASSWORD_HISTORY 10
-- PASSWORD_EXPIRE
- 设置当前用户密码的过期时间。如 PASSWORD_EXPIRE INTERVAL 10 DAY 表示密码会在 10
天后过期。PASSWORD_EXPIRE NEVER 表示密码不过期。如果设置为 PASSWORD_EXPIRE DEFAULT，则会使用全局变量
default_password_lifetime 中的值（单位为 天）。默认为 NEVER（或 0），表示不会过期。
+
+ - 设置全局变量：`SET GLOBAL password_history = 10`
+ - 为用户设置：`ALTER USER user1@'ip' PASSWORD_HISTORY 10`
+
+- `PASSWORD_EXPIRE`
+
+ 设置当前用户密码的过期时间。如 `PASSWORD_EXPIRE INTERVAL 10 DAY` 表示密码会在 10
天后过期。`PASSWORD_EXPIRE NEVER` 表示密码不过期。如果设置为 `PASSWORD_EXPIRE DEFAULT`，则会使用全局变量
`default_password_lifetime` 中的值（单位为 天）。默认为 NEVER（或 0），表示不会过期。
+
示例：
- - 设置全局变量：SET GLOBAL default_password_lifetime = 1
- - 为用户设置：ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY
-- FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME
- 设置当前用户登录时，如果使用错误的密码登录 n 次后，账户将被锁定，并设置锁定时间。如 FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY 表示如果 3 次错误登录，则账户会被锁定一天。管理员可以通过 ALTER USER 语句主动解锁被锁定的账户。
+
+ - 设置全局变量：`SET GLOBAL default_password_lifetime = 1`
+ - 为用户设置：`ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+
+- `FAILED_LOGIN_ATTEMPTS` 和 `PASSWORD_LOCK_TIME`
+
+ 设置当前用户登录时，如果使用错误的密码登录 n 次后，账户将被锁定，并设置锁定时间。如 `FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY` 表示如果 3 次错误登录，则账户会被锁定一天。管理员可以通过 ALTER USER
语句主动解锁被锁定的账户。
+
示例：
- - 为用户设置：ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1
DAY
+
+ - 为用户设置：`ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1
DAY`
+
- 密码强度
- 该功能由全局变量 validate_password_policy 控制。默认为 NONE/0，即不检查密码强度。如果设置为
STRONG/2，则密码必须包含“大写字母”，“小写字母”，“数字”和“特殊字符”中的 3 项，并且长度必须大于等于 8。
+
+ 该功能由全局变量 `validate_password_policy` 控制。默认为 NONE/0，即不检查密码强度。如果设置为
STRONG/2，则密码必须包含“大写字母”，“小写字母”，“数字”和“特殊字符”中的 3 项，并且长度必须大于等于 8。
+
示例：
- - SET validate_password_policy=STRONG
+
+ - `SET validate_password_policy=STRONG`
+
+以上策略设置后，可以通过如下命令查看：
+
+```sql
+SHOW PROC "/auth/'<user>'@'<host>'";
+```
+
+注意，需要使用单引号分别包裹 user 和 host 部分。比如：
+
+```
+SHOW PROC "/auth/'root'@'%'";
+SHOW PROC "/auth/'user1'@'127.0.0.1'";
+```
+
## 认证机制
+
1. 客户端认证信息发送：客户端将用户的信息（如用户名、密码、数据库等）打包发送给 Doris 服务器。这些信息用于证明客户端的身份和请求访问的数据库。
+
2. 服务器认证：Doris 收到客户端的认证信息后，会进行验证。如果用户名、密码以及客户端的 IP
正确，并且该用户具有访问所选数据库的权限，则认证成功，Doris 会将用户个体映射到系统内的用户标识（User
Identity）上。否则，认证失败，并返回相应的错误消息给客户端。
+
## 黑白名单
+
Doris 本身不支持黑名单，只有白名单功能，但我们可以通过某些方式来模拟黑名单。假设先创建了名为 `user@'192.%'` 的用户，表示允许来自
`192.*` 的用户登录。此时如果想禁止来自 `192.168.10.1` 的用户登录，则可以再创建一个用户
`cmy@'192.168.10.1'`，并设置一个新的密码。因为 `192.168.10.1` 的优先级高于 `192.%`，所以来自
`192.168.10.1` 的用户将不能再使用旧密码进行登录。
+
## 相关命令
+
- 创建用户：[CREATE
USER](../../../sql-manual/sql-statements/account-management/CREATE-USER)
- 查看用户：[SHOW ALL
GRANTS](../../../sql-manual/sql-statements/account-management/SHOW-GRANTS)
- 修改用户：[ALTER
USER](../../../sql-manual/sql-statements/account-management/ALTER-USER)
@@ -53,40 +97,53 @@ Doris 本身不支持黑名单，只有白名单功能，但我们可以通过
- 删除用户：[DROP
USER](../../../sql-manual/sql-statements/account-management/DROP-USER)
- 设置用户属性：[SET
PROPERTY](../../../sql-manual/sql-statements/account-management/SET-PROPERTY)
- 查看用户属性：[SHOW
PROPERTY](../../../sql-manual/sql-statements/account-management/SHOW-PROPERTY)
+
## 其它说明
- 1. 登录时 user_identity 优先级选择问题
- 如上文介绍，`user_identity` 由 `user_name` 和 `host` 组成，但是用户登录的时候，只需要输入
`user_name`，所以由 Doris 根据客户端的 IP 来匹配相应的 `host`，从而决定使用哪个 `user_identity` 登录。
+1. 登录时 user_identity 优先级选择问题
+
+ 如上文介绍，`user_identity` 由 `user_name` 和 `host` 组成，但是用户登录的时候，只需要输入
`user_name`，所以由 Doris 根据客户端的 IP 来匹配相应的 `host`，从而决定使用哪个 `user_identity` 登录。
+
+ 如果 根据 客户端 ip 只能匹配到一个 `user_identity`，那么毫无疑问会匹配到这个
`user_identity`，但是当能够匹配到多个 `user_identity` 时，就会有如下的优先级问题。
- 如果 根据 客户端 ip 只能匹配到一个 user_identity，那么毫无疑问会匹配到这个 user_identity，但是当能够匹配到多个
user_identity 时，就会有如下的优先级问题。
- 1. 域名与 ip 的优先级：
- 假设创建了如下用户：
- ```sql
- CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
- CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
- ```
- domain1 被解析为两个 IP：ip1 和 ip2。
+ 1. 域名与 ip 的优先级：
- 在优先级上，ip 优先于 域名，因此，当用户 user1 从 ip1 这台机器尝试使用密码 '12345' 登录 Doris 会被拒绝。
- 2. 具体 ip 和 范围 ip 的优先级：
假设创建了如下用户：
+
```sql
- CREATE USER user1@'%' IDENTIFIED BY "12345";
- CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
+ CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
```
- 在优先级上，'192.%' 优先于 '%'，因此，当用户 user1 从 192.168.1.1 这台机器尝试使用密码 '12345' 登录
Doris 会被拒绝。
- 2. 忘记密码
-
- 如果忘记了密码无法登录 Doris，可以在 FE 的 config 文件中添加 skip_localhost_auth_check=true
参数，并且重启 FE，从而无密码在 Fe 本机通过 root 登录 Doris。
-
- 登录后，可以通过 SET PASSWORD 命令重置密码。
- 3. 任何用户都不能重置 root 用户的密码，除了 root 用户自己。
- 4. `current_user()` 和 `user()`
-
- 用户可以通过 `SELECT current_user()` 和 `SELECT user()` 分别查看 `current_user` 和
`user`。其中 `current_user` 表示当前用户是以哪种身份通过认证系统的，而 `user` 则是用户当前实际的 User Identity。
-
- 举例说明：
-
- 假设创建了 `user1@'192.%'` 这个用户，然后以为来自 `192.168.10.1` 的用户 `user1`
登录了系统，则此时的 `current_user` 为 `user1@'192.%'`，而 `user` 为 `user1@'192.168.10.1'`。
-
- 所有的权限都是赋予某一个 `current_user` 的，真实用户拥有对应的 `current_user` 的所有权限。
+
+ domain1 被解析为两个 IP：ip1 和 ip2。
+
+ 在优先级上，ip 优先于 域名，因此，当用户 user1 从 ip1 这台机器尝试使用密码 '12345' 登录 Doris 会被拒绝。
+
+ 2. 具体 ip 和 范围 ip 的优先级：
+
+ 假设创建了如下用户：
+
+ ```sql
+ CREATE USER user1@'%' IDENTIFIED BY "12345";
+ CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ ```
+
+ 在优先级上，'192.%' 优先于 '%'，因此，当用户 user1 从 192.168.1.1 这台机器尝试使用密码 '12345' 登录
Doris 会被拒绝。
+
+2. 忘记密码
+
+ 如果忘记了密码无法登录 Doris，可以在 FE 的 config 文件中添加 skip_localhost_auth_check=true
参数，并且重启 FE，从而无密码在 Fe 本机通过 root 登录 Doris。
+
+ 登录后，可以通过 SET PASSWORD 命令重置密码。
+
+3. 任何用户都不能重置 root 用户的密码，除了 root 用户自己。
+
+4. `current_user()` 和 `user()`
+
+ 用户可以通过 `SELECT current_user()` 和 `SELECT user()` 分别查看 `current_user` 和
`user`。其中 `current_user` 表示当前用户是以哪种身份通过认证系统的，而 `user` 则是用户当前实际的 User Identity。
+
+ 举例说明：
+
+ 假设创建了 `user1@'192.%'` 这个用户，然后以为来自 `192.168.10.1` 的用户 `user1` 登录了系统，则此时的
`current_user` 为 `user1@'192.%'`，而 `user` 为 `user1@'192.168.10.1'`。
+
+ 所有的权限都是赋予某一个 `current_user` 的，真实用户拥有对应的 `current_user` 的所有权限。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/auth/authentication/internal.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/auth/authentication/internal.md
index c835ecbc3b9..d1eb716fc99 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/auth/authentication/internal.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/auth/authentication/internal.md
@@ -7,45 +7,89 @@
## 关键概念
### 用户
+
在 Doris 中，一个 user_identity 唯一标识一个用户。user_identity 由两部分组成，user_name 和 host，其中
username 为用户名。host 标识用户端连接所在的主机地址。host 部分可以使用 % 进行模糊匹配。如果不指定 host，默认为
'%'，即表示该用户可以从任意 host 连接到 Doris。
+
#### 用户属性
+
用户属性直接附属于 user_name，而不是 user_identity，即 user@'192.%' 和 user@['domain']
都拥有同一组用户属性。该属性属于 user，而不是 user@'192.%' 或 user@['domain']。
用户属性包括但不限于：用户最大连接数、导入集群配置等等。
+
#### 内置用户
+
内置用户是 Doris 默认创建的用户，并默认拥有一定的权限，包括 root 和 admin。初始密码都为空，fe
启动后，可以通过修改密码命令进行修改。不支持删除默认用户。
+
- root@'%'：root 用户，允许从任意节点登录，角色为 operator。
- admin@'%'：admin 用户，允许从任意节点登录，角色为 admin。
### 密码
+
用户登录的凭据，管理员创建用户时设置，也可以创建后由用户自己更改密码。
#### 密码策略
+
Doris 支持以下密码策略，可以帮助用户更好的进行密码管理。
-- PASSWORD_HISTORY
- 是否允许当前用户重置密码时使用历史密码。如 PASSWORD_HISTORY 10 表示禁止使用过去 10 次设置过的密码为新密码。如果设置为
PASSWORD_HISTORY DEFAULT，则会使用全局变量 password_history 中的值。0 表示不启用这个功能。默认为 0。
+
+- `PASSWORD_HISTORY`
+
+ 是否允许当前用户重置密码时使用历史密码。如 `PASSWORD_HISTORY` 10 表示禁止使用过去 10 次设置过的密码为新密码。如果设置为
`PASSWORD_HISTORY DEFAULT`，则会使用全局变量 `password_history` 中的值。0 表示不启用这个功能。默认为 0。
+
示例：
- - 设置全局变量：SET GLOBAL password_history = 10
- - 为用户设置：ALTER USER user1@'ip' PASSWORD_HISTORY 10
-- PASSWORD_EXPIRE
- 设置当前用户密码的过期时间。如 PASSWORD_EXPIRE INTERVAL 10 DAY 表示密码会在 10
天后过期。PASSWORD_EXPIRE NEVER 表示密码不过期。如果设置为 PASSWORD_EXPIRE DEFAULT，则会使用全局变量
default_password_lifetime 中的值（单位为 天）。默认为 NEVER（或 0），表示不会过期。
+
+ - 设置全局变量：`SET GLOBAL password_history = 10`
+ - 为用户设置：`ALTER USER user1@'ip' PASSWORD_HISTORY 10`
+
+- `PASSWORD_EXPIRE`
+
+ 设置当前用户密码的过期时间。如 `PASSWORD_EXPIRE INTERVAL 10 DAY` 表示密码会在 10
天后过期。`PASSWORD_EXPIRE NEVER` 表示密码不过期。如果设置为 `PASSWORD_EXPIRE DEFAULT`，则会使用全局变量
`default_password_lifetime` 中的值（单位为 天）。默认为 NEVER（或 0），表示不会过期。
+
示例：
- - 设置全局变量：SET GLOBAL default_password_lifetime = 1
- - 为用户设置：ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY
-- FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME
- 设置当前用户登录时，如果使用错误的密码登录 n 次后，账户将被锁定，并设置锁定时间。如 FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY 表示如果 3 次错误登录，则账户会被锁定一天。管理员可以通过 ALTER USER 语句主动解锁被锁定的账户。
+
+ - 设置全局变量：`SET GLOBAL default_password_lifetime = 1`
+ - 为用户设置：`ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+
+- `FAILED_LOGIN_ATTEMPTS` 和 `PASSWORD_LOCK_TIME`
+
+ 设置当前用户登录时，如果使用错误的密码登录 n 次后，账户将被锁定，并设置锁定时间。如 `FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY` 表示如果 3 次错误登录，则账户会被锁定一天。管理员可以通过 ALTER USER
语句主动解锁被锁定的账户。
+
示例：
- - 为用户设置：ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1
DAY
+
+ - 为用户设置：`ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1
DAY`
+
- 密码强度
- 该功能由全局变量 validate_password_policy 控制。默认为 NONE/0，即不检查密码强度。如果设置为
STRONG/2，则密码必须包含“大写字母”，“小写字母”，“数字”和“特殊字符”中的 3 项，并且长度必须大于等于 8。
+
+ 该功能由全局变量 `validate_password_policy` 控制。默认为 NONE/0，即不检查密码强度。如果设置为
STRONG/2，则密码必须包含“大写字母”，“小写字母”，“数字”和“特殊字符”中的 3 项，并且长度必须大于等于 8。
+
示例：
- - SET validate_password_policy=STRONG
+
+ - `SET validate_password_policy=STRONG`
+
+以上策略设置后，可以通过如下命令查看：
+
+```sql
+SHOW PROC "/auth/'<user>'@'<host>'";
+```
+
+注意，需要使用单引号分别包裹 user 和 host 部分。比如：
+
+```
+SHOW PROC "/auth/'root'@'%'";
+SHOW PROC "/auth/'user1'@'127.0.0.1'";
+```
+
## 认证机制
+
1. 客户端认证信息发送：客户端将用户的信息（如用户名、密码、数据库等）打包发送给 Doris 服务器。这些信息用于证明客户端的身份和请求访问的数据库。
+
2. 服务器认证：Doris 收到客户端的认证信息后，会进行验证。如果用户名、密码以及客户端的 IP
正确，并且该用户具有访问所选数据库的权限，则认证成功，Doris 会将用户个体映射到系统内的用户标识（User
Identity）上。否则，认证失败，并返回相应的错误消息给客户端。
+
## 黑白名单
+
Doris 本身不支持黑名单，只有白名单功能，但我们可以通过某些方式来模拟黑名单。假设先创建了名为 `user@'192.%'` 的用户，表示允许来自
`192.*` 的用户登录。此时如果想禁止来自 `192.168.10.1` 的用户登录，则可以再创建一个用户
`cmy@'192.168.10.1'`，并设置一个新的密码。因为 `192.168.10.1` 的优先级高于 `192.%`，所以来自
`192.168.10.1` 的用户将不能再使用旧密码进行登录。
+
## 相关命令
+
- 创建用户：[CREATE
USER](../../../sql-manual/sql-statements/account-management/CREATE-USER)
- 查看用户：[SHOW ALL
GRANTS](../../../sql-manual/sql-statements/account-management/SHOW-GRANTS)
- 修改用户：[ALTER
USER](../../../sql-manual/sql-statements/account-management/ALTER-USER)
@@ -53,40 +97,53 @@ Doris 本身不支持黑名单，只有白名单功能，但我们可以通过
- 删除用户：[DROP
USER](../../../sql-manual/sql-statements/account-management/DROP-USER)
- 设置用户属性：[SET
PROPERTY](../../../sql-manual/sql-statements/account-management/SET-PROPERTY)
- 查看用户属性：[SHOW
PROPERTY](../../../sql-manual/sql-statements/account-management/SHOW-PROPERTY)
+
## 其它说明
- 1. 登录时 user_identity 优先级选择问题
- 如上文介绍，`user_identity` 由 `user_name` 和 `host` 组成，但是用户登录的时候，只需要输入
`user_name`，所以由 Doris 根据客户端的 IP 来匹配相应的 `host`，从而决定使用哪个 `user_identity` 登录。
+1. 登录时 user_identity 优先级选择问题
+
+ 如上文介绍，`user_identity` 由 `user_name` 和 `host` 组成，但是用户登录的时候，只需要输入
`user_name`，所以由 Doris 根据客户端的 IP 来匹配相应的 `host`，从而决定使用哪个 `user_identity` 登录。
+
+ 如果 根据 客户端 ip 只能匹配到一个 `user_identity`，那么毫无疑问会匹配到这个
`user_identity`，但是当能够匹配到多个 `user_identity` 时，就会有如下的优先级问题。
- 如果 根据 客户端 ip 只能匹配到一个 user_identity，那么毫无疑问会匹配到这个 user_identity，但是当能够匹配到多个
user_identity 时，就会有如下的优先级问题。
- 1. 域名与 ip 的优先级：
- 假设创建了如下用户：
- ```sql
- CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
- CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
- ```
- domain1 被解析为两个 IP：ip1 和 ip2。
+ 1. 域名与 ip 的优先级：
- 在优先级上，ip 优先于 域名，因此，当用户 user1 从 ip1 这台机器尝试使用密码 '12345' 登录 Doris 会被拒绝。
- 2. 具体 ip 和 范围 ip 的优先级：
假设创建了如下用户：
+
```sql
- CREATE USER user1@'%' IDENTIFIED BY "12345";
- CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
+ CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
```
- 在优先级上，'192.%' 优先于 '%'，因此，当用户 user1 从 192.168.1.1 这台机器尝试使用密码 '12345' 登录
Doris 会被拒绝。
- 2. 忘记密码
-
- 如果忘记了密码无法登录 Doris，可以在 FE 的 config 文件中添加 skip_localhost_auth_check=true
参数，并且重启 FE，从而无密码在 Fe 本机通过 root 登录 Doris。
-
- 登录后，可以通过 SET PASSWORD 命令重置密码。
- 3. 任何用户都不能重置 root 用户的密码，除了 root 用户自己。
- 4. `current_user()` 和 `user()`
-
- 用户可以通过 `SELECT current_user()` 和 `SELECT user()` 分别查看 `current_user` 和
`user`。其中 `current_user` 表示当前用户是以哪种身份通过认证系统的，而 `user` 则是用户当前实际的 User Identity。
-
- 举例说明：
-
- 假设创建了 `user1@'192.%'` 这个用户，然后以为来自 `192.168.10.1` 的用户 `user1`
登录了系统，则此时的 `current_user` 为 `user1@'192.%'`，而 `user` 为 `user1@'192.168.10.1'`。
-
- 所有的权限都是赋予某一个 `current_user` 的，真实用户拥有对应的 `current_user` 的所有权限。
+
+ domain1 被解析为两个 IP：ip1 和 ip2。
+
+ 在优先级上，ip 优先于 域名，因此，当用户 user1 从 ip1 这台机器尝试使用密码 '12345' 登录 Doris 会被拒绝。
+
+ 2. 具体 ip 和 范围 ip 的优先级：
+
+ 假设创建了如下用户：
+
+ ```sql
+ CREATE USER user1@'%' IDENTIFIED BY "12345";
+ CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ ```
+
+ 在优先级上，'192.%' 优先于 '%'，因此，当用户 user1 从 192.168.1.1 这台机器尝试使用密码 '12345' 登录
Doris 会被拒绝。
+
+2. 忘记密码
+
+ 如果忘记了密码无法登录 Doris，可以在 FE 的 config 文件中添加 skip_localhost_auth_check=true
参数，并且重启 FE，从而无密码在 Fe 本机通过 root 登录 Doris。
+
+ 登录后，可以通过 SET PASSWORD 命令重置密码。
+
+3. 任何用户都不能重置 root 用户的密码，除了 root 用户自己。
+
+4. `current_user()` 和 `user()`
+
+ 用户可以通过 `SELECT current_user()` 和 `SELECT user()` 分别查看 `current_user` 和
`user`。其中 `current_user` 表示当前用户是以哪种身份通过认证系统的，而 `user` 则是用户当前实际的 User Identity。
+
+ 举例说明：
+
+ 假设创建了 `user1@'192.%'` 这个用户，然后以为来自 `192.168.10.1` 的用户 `user1` 登录了系统，则此时的
`current_user` 为 `user1@'192.%'`，而 `user` 为 `user1@'192.168.10.1'`。
+
+ 所有的权限都是赋予某一个 `current_user` 的，真实用户拥有对应的 `current_user` 的所有权限。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/admin-manual/auth/authentication/internal.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/admin-manual/auth/authentication/internal.md
index c835ecbc3b9..d1eb716fc99 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/admin-manual/auth/authentication/internal.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/admin-manual/auth/authentication/internal.md
@@ -7,45 +7,89 @@
## 关键概念
### 用户
+
在 Doris 中，一个 user_identity 唯一标识一个用户。user_identity 由两部分组成，user_name 和 host，其中
username 为用户名。host 标识用户端连接所在的主机地址。host 部分可以使用 % 进行模糊匹配。如果不指定 host，默认为
'%'，即表示该用户可以从任意 host 连接到 Doris。
+
#### 用户属性
+
用户属性直接附属于 user_name，而不是 user_identity，即 user@'192.%' 和 user@['domain']
都拥有同一组用户属性。该属性属于 user，而不是 user@'192.%' 或 user@['domain']。
用户属性包括但不限于：用户最大连接数、导入集群配置等等。
+
#### 内置用户
+
内置用户是 Doris 默认创建的用户，并默认拥有一定的权限，包括 root 和 admin。初始密码都为空，fe
启动后，可以通过修改密码命令进行修改。不支持删除默认用户。
+
- root@'%'：root 用户，允许从任意节点登录，角色为 operator。
- admin@'%'：admin 用户，允许从任意节点登录，角色为 admin。
### 密码
+
用户登录的凭据，管理员创建用户时设置，也可以创建后由用户自己更改密码。
#### 密码策略
+
Doris 支持以下密码策略，可以帮助用户更好的进行密码管理。
-- PASSWORD_HISTORY
- 是否允许当前用户重置密码时使用历史密码。如 PASSWORD_HISTORY 10 表示禁止使用过去 10 次设置过的密码为新密码。如果设置为
PASSWORD_HISTORY DEFAULT，则会使用全局变量 password_history 中的值。0 表示不启用这个功能。默认为 0。
+
+- `PASSWORD_HISTORY`
+
+ 是否允许当前用户重置密码时使用历史密码。如 `PASSWORD_HISTORY` 10 表示禁止使用过去 10 次设置过的密码为新密码。如果设置为
`PASSWORD_HISTORY DEFAULT`，则会使用全局变量 `password_history` 中的值。0 表示不启用这个功能。默认为 0。
+
示例：
- - 设置全局变量：SET GLOBAL password_history = 10
- - 为用户设置：ALTER USER user1@'ip' PASSWORD_HISTORY 10
-- PASSWORD_EXPIRE
- 设置当前用户密码的过期时间。如 PASSWORD_EXPIRE INTERVAL 10 DAY 表示密码会在 10
天后过期。PASSWORD_EXPIRE NEVER 表示密码不过期。如果设置为 PASSWORD_EXPIRE DEFAULT，则会使用全局变量
default_password_lifetime 中的值（单位为 天）。默认为 NEVER（或 0），表示不会过期。
+
+ - 设置全局变量：`SET GLOBAL password_history = 10`
+ - 为用户设置：`ALTER USER user1@'ip' PASSWORD_HISTORY 10`
+
+- `PASSWORD_EXPIRE`
+
+ 设置当前用户密码的过期时间。如 `PASSWORD_EXPIRE INTERVAL 10 DAY` 表示密码会在 10
天后过期。`PASSWORD_EXPIRE NEVER` 表示密码不过期。如果设置为 `PASSWORD_EXPIRE DEFAULT`，则会使用全局变量
`default_password_lifetime` 中的值（单位为 天）。默认为 NEVER（或 0），表示不会过期。
+
示例：
- - 设置全局变量：SET GLOBAL default_password_lifetime = 1
- - 为用户设置：ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY
-- FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME
- 设置当前用户登录时，如果使用错误的密码登录 n 次后，账户将被锁定，并设置锁定时间。如 FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY 表示如果 3 次错误登录，则账户会被锁定一天。管理员可以通过 ALTER USER 语句主动解锁被锁定的账户。
+
+ - 设置全局变量：`SET GLOBAL default_password_lifetime = 1`
+ - 为用户设置：`ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+
+- `FAILED_LOGIN_ATTEMPTS` 和 `PASSWORD_LOCK_TIME`
+
+ 设置当前用户登录时，如果使用错误的密码登录 n 次后，账户将被锁定，并设置锁定时间。如 `FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY` 表示如果 3 次错误登录，则账户会被锁定一天。管理员可以通过 ALTER USER
语句主动解锁被锁定的账户。
+
示例：
- - 为用户设置：ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1
DAY
+
+ - 为用户设置：`ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1
DAY`
+
- 密码强度
- 该功能由全局变量 validate_password_policy 控制。默认为 NONE/0，即不检查密码强度。如果设置为
STRONG/2，则密码必须包含“大写字母”，“小写字母”，“数字”和“特殊字符”中的 3 项，并且长度必须大于等于 8。
+
+ 该功能由全局变量 `validate_password_policy` 控制。默认为 NONE/0，即不检查密码强度。如果设置为
STRONG/2，则密码必须包含“大写字母”，“小写字母”，“数字”和“特殊字符”中的 3 项，并且长度必须大于等于 8。
+
示例：
- - SET validate_password_policy=STRONG
+
+ - `SET validate_password_policy=STRONG`
+
+以上策略设置后，可以通过如下命令查看：
+
+```sql
+SHOW PROC "/auth/'<user>'@'<host>'";
+```
+
+注意，需要使用单引号分别包裹 user 和 host 部分。比如：
+
+```
+SHOW PROC "/auth/'root'@'%'";
+SHOW PROC "/auth/'user1'@'127.0.0.1'";
+```
+
## 认证机制
+
1. 客户端认证信息发送：客户端将用户的信息（如用户名、密码、数据库等）打包发送给 Doris 服务器。这些信息用于证明客户端的身份和请求访问的数据库。
+
2. 服务器认证：Doris 收到客户端的认证信息后，会进行验证。如果用户名、密码以及客户端的 IP
正确，并且该用户具有访问所选数据库的权限，则认证成功，Doris 会将用户个体映射到系统内的用户标识（User
Identity）上。否则，认证失败，并返回相应的错误消息给客户端。
+
## 黑白名单
+
Doris 本身不支持黑名单，只有白名单功能，但我们可以通过某些方式来模拟黑名单。假设先创建了名为 `user@'192.%'` 的用户，表示允许来自
`192.*` 的用户登录。此时如果想禁止来自 `192.168.10.1` 的用户登录，则可以再创建一个用户
`cmy@'192.168.10.1'`，并设置一个新的密码。因为 `192.168.10.1` 的优先级高于 `192.%`，所以来自
`192.168.10.1` 的用户将不能再使用旧密码进行登录。
+
## 相关命令
+
- 创建用户：[CREATE
USER](../../../sql-manual/sql-statements/account-management/CREATE-USER)
- 查看用户：[SHOW ALL
GRANTS](../../../sql-manual/sql-statements/account-management/SHOW-GRANTS)
- 修改用户：[ALTER
USER](../../../sql-manual/sql-statements/account-management/ALTER-USER)
@@ -53,40 +97,53 @@ Doris 本身不支持黑名单，只有白名单功能，但我们可以通过
- 删除用户：[DROP
USER](../../../sql-manual/sql-statements/account-management/DROP-USER)
- 设置用户属性：[SET
PROPERTY](../../../sql-manual/sql-statements/account-management/SET-PROPERTY)
- 查看用户属性：[SHOW
PROPERTY](../../../sql-manual/sql-statements/account-management/SHOW-PROPERTY)
+
## 其它说明
- 1. 登录时 user_identity 优先级选择问题
- 如上文介绍，`user_identity` 由 `user_name` 和 `host` 组成，但是用户登录的时候，只需要输入
`user_name`，所以由 Doris 根据客户端的 IP 来匹配相应的 `host`，从而决定使用哪个 `user_identity` 登录。
+1. 登录时 user_identity 优先级选择问题
+
+ 如上文介绍，`user_identity` 由 `user_name` 和 `host` 组成，但是用户登录的时候，只需要输入
`user_name`，所以由 Doris 根据客户端的 IP 来匹配相应的 `host`，从而决定使用哪个 `user_identity` 登录。
+
+ 如果 根据 客户端 ip 只能匹配到一个 `user_identity`，那么毫无疑问会匹配到这个
`user_identity`，但是当能够匹配到多个 `user_identity` 时，就会有如下的优先级问题。
- 如果 根据 客户端 ip 只能匹配到一个 user_identity，那么毫无疑问会匹配到这个 user_identity，但是当能够匹配到多个
user_identity 时，就会有如下的优先级问题。
- 1. 域名与 ip 的优先级：
- 假设创建了如下用户：
- ```sql
- CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
- CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
- ```
- domain1 被解析为两个 IP：ip1 和 ip2。
+ 1. 域名与 ip 的优先级：
- 在优先级上，ip 优先于 域名，因此，当用户 user1 从 ip1 这台机器尝试使用密码 '12345' 登录 Doris 会被拒绝。
- 2. 具体 ip 和 范围 ip 的优先级：
假设创建了如下用户：
+
```sql
- CREATE USER user1@'%' IDENTIFIED BY "12345";
- CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
+ CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
```
- 在优先级上，'192.%' 优先于 '%'，因此，当用户 user1 从 192.168.1.1 这台机器尝试使用密码 '12345' 登录
Doris 会被拒绝。
- 2. 忘记密码
-
- 如果忘记了密码无法登录 Doris，可以在 FE 的 config 文件中添加 skip_localhost_auth_check=true
参数，并且重启 FE，从而无密码在 Fe 本机通过 root 登录 Doris。
-
- 登录后，可以通过 SET PASSWORD 命令重置密码。
- 3. 任何用户都不能重置 root 用户的密码，除了 root 用户自己。
- 4. `current_user()` 和 `user()`
-
- 用户可以通过 `SELECT current_user()` 和 `SELECT user()` 分别查看 `current_user` 和
`user`。其中 `current_user` 表示当前用户是以哪种身份通过认证系统的，而 `user` 则是用户当前实际的 User Identity。
-
- 举例说明：
-
- 假设创建了 `user1@'192.%'` 这个用户，然后以为来自 `192.168.10.1` 的用户 `user1`
登录了系统，则此时的 `current_user` 为 `user1@'192.%'`，而 `user` 为 `user1@'192.168.10.1'`。
-
- 所有的权限都是赋予某一个 `current_user` 的，真实用户拥有对应的 `current_user` 的所有权限。
+
+ domain1 被解析为两个 IP：ip1 和 ip2。
+
+ 在优先级上，ip 优先于 域名，因此，当用户 user1 从 ip1 这台机器尝试使用密码 '12345' 登录 Doris 会被拒绝。
+
+ 2. 具体 ip 和 范围 ip 的优先级：
+
+ 假设创建了如下用户：
+
+ ```sql
+ CREATE USER user1@'%' IDENTIFIED BY "12345";
+ CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ ```
+
+ 在优先级上，'192.%' 优先于 '%'，因此，当用户 user1 从 192.168.1.1 这台机器尝试使用密码 '12345' 登录
Doris 会被拒绝。
+
+2. 忘记密码
+
+ 如果忘记了密码无法登录 Doris，可以在 FE 的 config 文件中添加 skip_localhost_auth_check=true
参数，并且重启 FE，从而无密码在 Fe 本机通过 root 登录 Doris。
+
+ 登录后，可以通过 SET PASSWORD 命令重置密码。
+
+3. 任何用户都不能重置 root 用户的密码，除了 root 用户自己。
+
+4. `current_user()` 和 `user()`
+
+ 用户可以通过 `SELECT current_user()` 和 `SELECT user()` 分别查看 `current_user` 和
`user`。其中 `current_user` 表示当前用户是以哪种身份通过认证系统的，而 `user` 则是用户当前实际的 User Identity。
+
+ 举例说明：
+
+ 假设创建了 `user1@'192.%'` 这个用户，然后以为来自 `192.168.10.1` 的用户 `user1` 登录了系统，则此时的
`current_user` 为 `user1@'192.%'`，而 `user` 为 `user1@'192.168.10.1'`。
+
+ 所有的权限都是赋予某一个 `current_user` 的，真实用户拥有对应的 `current_user` 的所有权限。
diff --git
a/versioned_docs/version-2.1/admin-manual/auth/authentication/internal.md
b/versioned_docs/version-2.1/admin-manual/auth/authentication/internal.md
index b720e9b2bf3..d9a69c56974 100644
--- a/versioned_docs/version-2.1/admin-manual/auth/authentication/internal.md
+++ b/versioned_docs/version-2.1/admin-manual/auth/authentication/internal.md
@@ -6,97 +6,144 @@
---
## Key Concepts
+### Users
-### User
-In Doris, a `user_identity` uniquely identifies a user. `user_identity`
consists of two parts: `user_name` and `host`, where `user_name` is the
username. `host` identifies the host address from which the user connects. The
`host` part can use `%` for fuzzy matching. If `host` is not specified, it
defaults to `%`, meaning the user can connect to Doris from any host.
+In Doris, a user_identity uniquely identifies a user. user_identity consists
of two parts: user_name and host, where username is the user name. host
identifies the host address where the user client connection is located. The
host part can use % for fuzzy matching. If host is not specified, it defaults
to '%', which means the user can connect to Doris from any host.
#### User Attributes
-User attributes are directly attached to `user_name`, not `user_identity`,
meaning `user@'192.%'` and `user@['domain']` share the same set of user
attributes. These attributes belong to the user, not `user@'192.%'` or
`user@['domain']`.
-User attributes include, but are not limited to: maximum number of user
connections, import cluster configuration, etc.
+User attributes are directly attached to user_name, not user_identity. This
means user@'192.%' and user@['domain'] both have the same set of user
attributes. These attributes belong to user, not to user@'192.%' or
user@['domain'].
+
+User attributes include but are not limited to: maximum user connections,
import cluster configuration, etc.
#### Built-in Users
-Built-in users are users created by default in Doris and have certain
permissions by default, including `root` and `admin`. Initial passwords are
empty and can be changed after the frontend starts using password modification
commands. Default users cannot be deleted.
-- `root@'%'`: Root user, allowed to log in from any node, role is operator.
-- `admin@'%'`: Admin user, allowed to log in from any node, role is admin.
+
+Built-in users are users created by default in Doris and have certain default
permissions, including root and admin. The initial passwords are empty. After
FE starts, you can modify them using the password change command. Built-in
users cannot be deleted.
+
+- root@'%': root user, allowed to log in from any node, with operator role.
+- admin@'%': admin user, allowed to log in from any node, with admin role.
### Password
-Credentials for user login, set by the administrator when creating the user,
can also be changed by the user after creation.
-#### Password Policy
-Doris supports the following password policies to help users manage passwords
better.
+User login credentials, set by administrators when creating users, or can be
changed by users themselves after creation.
+
+#### Password Policies
+
+Doris supports the following password policies to help users better manage
passwords.
+
- `PASSWORD_HISTORY`
- Whether the current user is allowed to use historical passwords when
resetting their password. For example, `PASSWORD_HISTORY 10` means that the
past 10 passwords cannot be reused as the new password. If set to
`PASSWORD_HISTORY DEFAULT`, the value of the global variable `password_history`
will be used. 0 means this feature is not enabled. The default is 0.
- Example:
- - Set global variable: `SET GLOBAL password_history = 10`
- - Set for user: `ALTER USER user1@'ip' PASSWORD_HISTORY 10`
+
+ Whether to allow the current user to use historical passwords when resetting
passwords. For example, `PASSWORD_HISTORY` 10 means prohibiting the use of the
last 10 passwords as new passwords. If set to `PASSWORD_HISTORY DEFAULT`, it
will use the value in the global variable `password_history`. 0 means this
feature is disabled. Default is 0.
+
+ Examples:
+
+ - Set global variable: `SET GLOBAL password_history = 10`
+ - Set for user: `ALTER USER user1@'ip' PASSWORD_HISTORY 10`
+
- `PASSWORD_EXPIRE`
- Set the password expiration time for the current user. For example,
`PASSWORD_EXPIRE INTERVAL 10 DAY` means the password will expire in 10 days.
`PASSWORD_EXPIRE NEVER` means the password will never expire. If set to
`PASSWORD_EXPIRE DEFAULT`, the value of the global variable
`default_password_lifetime` will be used (in days). The default is `NEVER` (or
0), meaning the password will not expire.
- Example:
- - Set global variable: `SET GLOBAL default_password_lifetime = 1`
- - Set for user: `ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+
+ Set the expiration time for the current user's password. For example,
`PASSWORD_EXPIRE INTERVAL 10 DAY` means the password will expire in 10 days.
`PASSWORD_EXPIRE NEVER` means the password never expires. If set to
`PASSWORD_EXPIRE DEFAULT`, it will use the value in the global variable
`default_password_lifetime` (in days). Default is NEVER (or 0), meaning it will
not expire.
+
+ Examples:
+
+ - Set global variable: `SET GLOBAL default_password_lifetime = 1`
+ - Set for user: `ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+
- `FAILED_LOGIN_ATTEMPTS` and `PASSWORD_LOCK_TIME`
- Set the number of incorrect password attempts before the account is locked
and the lock time. For example, `FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1
DAY` means the account will be locked for one day after 3 incorrect login
attempts. Administrators can unlock locked accounts using the `ALTER USER`
statement.
- Example:
- - Set for user: `ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY`
+
+ Set that when the current user logs in with wrong password n times, the
account will be locked and set a lock time. For example, `FAILED_LOGIN_ATTEMPTS
3 PASSWORD_LOCK_TIME 1 DAY` means if there are 3 wrong logins, the account will
be locked for one day. Administrators can actively unlock locked accounts
through ALTER USER statements.
+
+ Examples:
+
+ - Set for user: `ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY`
+
- Password Strength
- Controlled by the global variable `validate_password_policy`. The default is
`NONE/0`, meaning no password strength check. If set to `STRONG/2`, the
password must contain at least 3 of the following: "uppercase letters",
"lowercase letters", "numbers", and "special characters", and the length must
be at least 8.
- Example:
+
+ This feature is controlled by the global variable
`validate_password_policy`. Default is NONE/0, meaning password strength is not
checked. If set to STRONG/2, the password must contain 3 of the following:
"uppercase letters", "lowercase letters", "numbers", and "special characters",
and the length must be greater than or equal to 8.
+
+ Examples:
+
- `SET validate_password_policy=STRONG`
+After setting the above policies, you can view them with the following command:
+
+```sql
+SHOW PROC "/auth/'<user>'@'<host>'";
+```
+
+Note that you need to wrap the user and host parts with single quotes
separately. For example:
+
+```
+SHOW PROC "/auth/'root'@'%'";
+SHOW PROC "/auth/'user1'@'127.0.0.1'";
+```
+
## Authentication Mechanism
-1. Client Authentication Information Sending: The client packages user
information (such as username, password, database, etc.) and sends it to the
Doris server. This information is used to prove the client's identity and
request access to the database.
-2. Server Authentication: After receiving the client's authentication
information, Doris verifies it. If the username, password, and client IP are
correct, and the user has permission to access the selected database,
authentication is successful, and Doris maps the user entity to the system's
user identity. Otherwise, authentication fails, and an error message is
returned to the client.
-## Whitelist and Blacklist
-Doris itself does not support a blacklist, only a whitelist function, but we
can simulate a blacklist in some ways. Suppose a user named `user@'192.%'` is
created, allowing users from 192.* to log in. If you want to prohibit users
from 192.168.10.1 from logging in, you can create another user
`cmy@'192.168.10.1'` and set a new password. Since 192.168.10.1 has a higher
priority than 192.%, users from 192.168.10.1 will no longer be able to log in
using the old password.
+1. Client authentication information sending: The client packages and sends
user information (such as username, password, database, etc.) to the Doris
server. This information is used to prove the client's identity and request
access to the database.
+
+2. Server authentication: After Doris receives the client's authentication
information, it performs verification. If the username, password, and client IP
are correct, and the user has permission to access the selected database,
authentication succeeds, and Doris will map the user individual to the User
Identity in the system. Otherwise, authentication fails and returns the
corresponding error message to the client.
+
+## Blacklist and Whitelist
+
+Doris itself does not support blacklists, only whitelist functionality, but we
can simulate blacklists in certain ways. Suppose we first created a user named
`user@'192.%'`, indicating that users from `192.*` are allowed to log in. If we
want to prohibit users from `192.168.10.1` from logging in, we can create
another user `cmy@'192.168.10.1'` and set a new password. Because
`192.168.10.1` has higher priority than `192.%`, users from `192.168.10.1` will
no longer be able to log in using [...]
## Related Commands
-- Create User: [CREATE
USER](../../../sql-manual/sql-statements/account-management/CREATE-USER)
-- View User: [SHOW ALL
GRANTS](../../../sql-manual/sql-statements/account-management/SHOW-GRANTS)
-- Modify User: [ALTER
USER](../../../sql-manual/sql-statements/account-management/ALTER-USER)
-- Change Password: [SET
PASSWORD](../../../sql-manual/sql-statements/account-management/SET-PASSWORD)
-- Delete User: [DROP
USER](../../../sql-manual/sql-statements/account-management/DROP-USER)
-- Set User Attributes: [SET
PROPERTY](../../../sql-manual/sql-statements/account-management/SET-PROPERTY)
-- View User Attributes: [SHOW
PROPERTY](../../../sql-manual/sql-statements/account-management/SHOW-PROPERTY)
-
-## Other Explanations
- 1. User Identity Priority Selection Issue During Login
-
- As introduced above, `user_identity` consists of `user_name` and `host`,
but when logging in, the user only needs to enter `user_name`, so Doris
determines based on the client's IP which `user_identity` to use for login.
-
- If only one `user_identity` can be matched based on the client's IP, it
will be used for login without any issues. However, if multiple `user_identity`
can be matched, there will be a priority issue.
- 1. Priority between domain name and IP:
- Suppose the following users are created:
- ```sql
- CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
- CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
- ```
- `domain1` is resolved to two IPs: `ip1` and `ip2`.
-
- In terms of priority, IP takes precedence over domain name.
Therefore, when user `user1` attempts to log in to Doris from `ip1` using
password `'12345'`, the login will be rejected.
- 2. Priority between specific IP and range IP:
- Suppose the following users are created:
+
+- Create user: [CREATE
USER](../../../sql-manual/sql-statements/account-management/CREATE-USER)
+- View users: [SHOW ALL
GRANTS](../../../sql-manual/sql-statements/account-management/SHOW-GRANTS)
+- Modify user: [ALTER
USER](../../../sql-manual/sql-statements/account-management/ALTER-USER)
+- Change password: [SET
PASSWORD](../../../sql-manual/sql-statements/account-management/SET-PASSWORD)
+- Delete user: [DROP
USER](../../../sql-manual/sql-statements/account-management/DROP-USER)
+- Set user attributes: [SET
PROPERTY](../../../sql-manual/sql-statements/account-management/SET-PROPERTY)
+- View user attributes: [SHOW
PROPERTY](../../../sql-manual/sql-statements/account-management/SHOW-PROPERTY)
+
+## Other Notes
+
+1. Priority selection of user_identity during login
+
+ As mentioned above, `user_identity` consists of `user_name` and `host`,
but when users log in, they only need to input `user_name`, so Doris matches
the corresponding `host` based on the client's IP to determine which
`user_identity` to use for login.
+
+ If only one `user_identity` can be matched based on the client IP, then
this `user_identity` will undoubtedly be matched. However, when multiple
`user_identity` can be matched, there will be the following priority issues.
+
+ 1. Priority between domain and IP:
+
+ Suppose the following users were created:
+
```sql
- CREATE USER user1@'%' IDENTIFIED BY "12345";
- CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
+ CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
```
- In terms of priority, `'192.%'` takes precedence over `'%'`.
Therefore, when user `user1` attempts to log in to Doris from `192.168.1.1`
using password `'12345'`, the login will be rejected.
- 2. Forgotten Password
+ domain1 is resolved to two IPs: ip1 and ip2.
+
+ In terms of priority, IP takes precedence over domain, so when user
user1 tries to log in to Doris from ip1 using password '12345', it will be
rejected.
+
+ 2. Priority between specific IP and IP range:
+
+ Suppose the following users were created:
+
+ ```sql
+ CREATE USER user1@'%' IDENTIFIED BY "12345";
+ CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ ```
+
+ In terms of priority, '192.%' takes precedence over '%', so when user
user1 tries to log in to Doris from 192.168.1.1 using password '12345', it will
be rejected.
+
+2. Forgot password
- If you forget your password and cannot log in to Doris, you can add the
`skip_localhost_auth_check=true` parameter to the FE's configuration file and
restart the FE. This will allow you to log in to Doris from the FE machine
without a password using the `root` user.
+ If you forget your password and cannot log in to Doris, you can add the
skip_localhost_auth_check=true parameter in the FE config file and restart FE,
so you can log in to Doris as root on the FE local machine without a password.
- After logging in, you can use the `SET PASSWORD` command to reset your
password.
+ After logging in, you can reset the password using the SET PASSWORD
command.
- 3. Any user cannot reset the password of the `root` user, except for the
`root` user itself.
+3. No user can reset the root user's password except the root user itself.
- 4. `current_user()` and `user()`
+4. `current_user()` and `user()`
- Users can use `SELECT current_user()` and `SELECT user()` to view
`current_user` and `user`, respectively. `current_user` indicates the identity
used by the current user to pass the authentication system, while `user` is the
actual User Identity of the current user.
+ Users can view `current_user` and `user` through `SELECT current_user()`
and `SELECT user()` respectively. `current_user` represents the identity
through which the current user passed the authentication system, while `user`
is the user's actual User Identity.
- For example:
+ Example:
- Suppose `user1@'192.%'` is created, and then a user named `user1` logs
in to the system from `192.168.10.1`. At this time, `current_user` is
`user1@'192.%'`, and `user` is `user1@'192.168.10.1'`.
+ Suppose we created the user `user1@'192.%'`, then user `user1` from
`192.168.10.1` logged into the system. In this case, `current_user` would be
`user1@'192.%'`, while `user` would be `user1@'192.168.10.1'`.
- All permissions are granted to a specific `current_user`, and the
actual user has all the permissions of the corresponding `current_user`.
+ All permissions are granted to a specific `current_user`, and the actual
user has all the permissions of the corresponding `current_user`.
\ No newline at end of file
diff --git
a/versioned_docs/version-3.x/admin-manual/auth/authentication/internal.md
b/versioned_docs/version-3.x/admin-manual/auth/authentication/internal.md
index b720e9b2bf3..d9a69c56974 100644
--- a/versioned_docs/version-3.x/admin-manual/auth/authentication/internal.md
+++ b/versioned_docs/version-3.x/admin-manual/auth/authentication/internal.md
@@ -6,97 +6,144 @@
---
## Key Concepts
+### Users
-### User
-In Doris, a `user_identity` uniquely identifies a user. `user_identity`
consists of two parts: `user_name` and `host`, where `user_name` is the
username. `host` identifies the host address from which the user connects. The
`host` part can use `%` for fuzzy matching. If `host` is not specified, it
defaults to `%`, meaning the user can connect to Doris from any host.
+In Doris, a user_identity uniquely identifies a user. user_identity consists
of two parts: user_name and host, where username is the user name. host
identifies the host address where the user client connection is located. The
host part can use % for fuzzy matching. If host is not specified, it defaults
to '%', which means the user can connect to Doris from any host.
#### User Attributes
-User attributes are directly attached to `user_name`, not `user_identity`,
meaning `user@'192.%'` and `user@['domain']` share the same set of user
attributes. These attributes belong to the user, not `user@'192.%'` or
`user@['domain']`.
-User attributes include, but are not limited to: maximum number of user
connections, import cluster configuration, etc.
+User attributes are directly attached to user_name, not user_identity. This
means user@'192.%' and user@['domain'] both have the same set of user
attributes. These attributes belong to user, not to user@'192.%' or
user@['domain'].
+
+User attributes include but are not limited to: maximum user connections,
import cluster configuration, etc.
#### Built-in Users
-Built-in users are users created by default in Doris and have certain
permissions by default, including `root` and `admin`. Initial passwords are
empty and can be changed after the frontend starts using password modification
commands. Default users cannot be deleted.
-- `root@'%'`: Root user, allowed to log in from any node, role is operator.
-- `admin@'%'`: Admin user, allowed to log in from any node, role is admin.
+
+Built-in users are users created by default in Doris and have certain default
permissions, including root and admin. The initial passwords are empty. After
FE starts, you can modify them using the password change command. Built-in
users cannot be deleted.
+
+- root@'%': root user, allowed to log in from any node, with operator role.
+- admin@'%': admin user, allowed to log in from any node, with admin role.
### Password
-Credentials for user login, set by the administrator when creating the user,
can also be changed by the user after creation.
-#### Password Policy
-Doris supports the following password policies to help users manage passwords
better.
+User login credentials, set by administrators when creating users, or can be
changed by users themselves after creation.
+
+#### Password Policies
+
+Doris supports the following password policies to help users better manage
passwords.
+
- `PASSWORD_HISTORY`
- Whether the current user is allowed to use historical passwords when
resetting their password. For example, `PASSWORD_HISTORY 10` means that the
past 10 passwords cannot be reused as the new password. If set to
`PASSWORD_HISTORY DEFAULT`, the value of the global variable `password_history`
will be used. 0 means this feature is not enabled. The default is 0.
- Example:
- - Set global variable: `SET GLOBAL password_history = 10`
- - Set for user: `ALTER USER user1@'ip' PASSWORD_HISTORY 10`
+
+ Whether to allow the current user to use historical passwords when resetting
passwords. For example, `PASSWORD_HISTORY` 10 means prohibiting the use of the
last 10 passwords as new passwords. If set to `PASSWORD_HISTORY DEFAULT`, it
will use the value in the global variable `password_history`. 0 means this
feature is disabled. Default is 0.
+
+ Examples:
+
+ - Set global variable: `SET GLOBAL password_history = 10`
+ - Set for user: `ALTER USER user1@'ip' PASSWORD_HISTORY 10`
+
- `PASSWORD_EXPIRE`
- Set the password expiration time for the current user. For example,
`PASSWORD_EXPIRE INTERVAL 10 DAY` means the password will expire in 10 days.
`PASSWORD_EXPIRE NEVER` means the password will never expire. If set to
`PASSWORD_EXPIRE DEFAULT`, the value of the global variable
`default_password_lifetime` will be used (in days). The default is `NEVER` (or
0), meaning the password will not expire.
- Example:
- - Set global variable: `SET GLOBAL default_password_lifetime = 1`
- - Set for user: `ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+
+ Set the expiration time for the current user's password. For example,
`PASSWORD_EXPIRE INTERVAL 10 DAY` means the password will expire in 10 days.
`PASSWORD_EXPIRE NEVER` means the password never expires. If set to
`PASSWORD_EXPIRE DEFAULT`, it will use the value in the global variable
`default_password_lifetime` (in days). Default is NEVER (or 0), meaning it will
not expire.
+
+ Examples:
+
+ - Set global variable: `SET GLOBAL default_password_lifetime = 1`
+ - Set for user: `ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY`
+
- `FAILED_LOGIN_ATTEMPTS` and `PASSWORD_LOCK_TIME`
- Set the number of incorrect password attempts before the account is locked
and the lock time. For example, `FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1
DAY` means the account will be locked for one day after 3 incorrect login
attempts. Administrators can unlock locked accounts using the `ALTER USER`
statement.
- Example:
- - Set for user: `ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY`
+
+ Set that when the current user logs in with wrong password n times, the
account will be locked and set a lock time. For example, `FAILED_LOGIN_ATTEMPTS
3 PASSWORD_LOCK_TIME 1 DAY` means if there are 3 wrong logins, the account will
be locked for one day. Administrators can actively unlock locked accounts
through ALTER USER statements.
+
+ Examples:
+
+ - Set for user: `ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 1 DAY`
+
- Password Strength
- Controlled by the global variable `validate_password_policy`. The default is
`NONE/0`, meaning no password strength check. If set to `STRONG/2`, the
password must contain at least 3 of the following: "uppercase letters",
"lowercase letters", "numbers", and "special characters", and the length must
be at least 8.
- Example:
+
+ This feature is controlled by the global variable
`validate_password_policy`. Default is NONE/0, meaning password strength is not
checked. If set to STRONG/2, the password must contain 3 of the following:
"uppercase letters", "lowercase letters", "numbers", and "special characters",
and the length must be greater than or equal to 8.
+
+ Examples:
+
- `SET validate_password_policy=STRONG`
+After setting the above policies, you can view them with the following command:
+
+```sql
+SHOW PROC "/auth/'<user>'@'<host>'";
+```
+
+Note that you need to wrap the user and host parts with single quotes
separately. For example:
+
+```
+SHOW PROC "/auth/'root'@'%'";
+SHOW PROC "/auth/'user1'@'127.0.0.1'";
+```
+
## Authentication Mechanism
-1. Client Authentication Information Sending: The client packages user
information (such as username, password, database, etc.) and sends it to the
Doris server. This information is used to prove the client's identity and
request access to the database.
-2. Server Authentication: After receiving the client's authentication
information, Doris verifies it. If the username, password, and client IP are
correct, and the user has permission to access the selected database,
authentication is successful, and Doris maps the user entity to the system's
user identity. Otherwise, authentication fails, and an error message is
returned to the client.
-## Whitelist and Blacklist
-Doris itself does not support a blacklist, only a whitelist function, but we
can simulate a blacklist in some ways. Suppose a user named `user@'192.%'` is
created, allowing users from 192.* to log in. If you want to prohibit users
from 192.168.10.1 from logging in, you can create another user
`cmy@'192.168.10.1'` and set a new password. Since 192.168.10.1 has a higher
priority than 192.%, users from 192.168.10.1 will no longer be able to log in
using the old password.
+1. Client authentication information sending: The client packages and sends
user information (such as username, password, database, etc.) to the Doris
server. This information is used to prove the client's identity and request
access to the database.
+
+2. Server authentication: After Doris receives the client's authentication
information, it performs verification. If the username, password, and client IP
are correct, and the user has permission to access the selected database,
authentication succeeds, and Doris will map the user individual to the User
Identity in the system. Otherwise, authentication fails and returns the
corresponding error message to the client.
+
+## Blacklist and Whitelist
+
+Doris itself does not support blacklists, only whitelist functionality, but we
can simulate blacklists in certain ways. Suppose we first created a user named
`user@'192.%'`, indicating that users from `192.*` are allowed to log in. If we
want to prohibit users from `192.168.10.1` from logging in, we can create
another user `cmy@'192.168.10.1'` and set a new password. Because
`192.168.10.1` has higher priority than `192.%`, users from `192.168.10.1` will
no longer be able to log in using [...]
## Related Commands
-- Create User: [CREATE
USER](../../../sql-manual/sql-statements/account-management/CREATE-USER)
-- View User: [SHOW ALL
GRANTS](../../../sql-manual/sql-statements/account-management/SHOW-GRANTS)
-- Modify User: [ALTER
USER](../../../sql-manual/sql-statements/account-management/ALTER-USER)
-- Change Password: [SET
PASSWORD](../../../sql-manual/sql-statements/account-management/SET-PASSWORD)
-- Delete User: [DROP
USER](../../../sql-manual/sql-statements/account-management/DROP-USER)
-- Set User Attributes: [SET
PROPERTY](../../../sql-manual/sql-statements/account-management/SET-PROPERTY)
-- View User Attributes: [SHOW
PROPERTY](../../../sql-manual/sql-statements/account-management/SHOW-PROPERTY)
-
-## Other Explanations
- 1. User Identity Priority Selection Issue During Login
-
- As introduced above, `user_identity` consists of `user_name` and `host`,
but when logging in, the user only needs to enter `user_name`, so Doris
determines based on the client's IP which `user_identity` to use for login.
-
- If only one `user_identity` can be matched based on the client's IP, it
will be used for login without any issues. However, if multiple `user_identity`
can be matched, there will be a priority issue.
- 1. Priority between domain name and IP:
- Suppose the following users are created:
- ```sql
- CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
- CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
- ```
- `domain1` is resolved to two IPs: `ip1` and `ip2`.
-
- In terms of priority, IP takes precedence over domain name.
Therefore, when user `user1` attempts to log in to Doris from `ip1` using
password `'12345'`, the login will be rejected.
- 2. Priority between specific IP and range IP:
- Suppose the following users are created:
+
+- Create user: [CREATE
USER](../../../sql-manual/sql-statements/account-management/CREATE-USER)
+- View users: [SHOW ALL
GRANTS](../../../sql-manual/sql-statements/account-management/SHOW-GRANTS)
+- Modify user: [ALTER
USER](../../../sql-manual/sql-statements/account-management/ALTER-USER)
+- Change password: [SET
PASSWORD](../../../sql-manual/sql-statements/account-management/SET-PASSWORD)
+- Delete user: [DROP
USER](../../../sql-manual/sql-statements/account-management/DROP-USER)
+- Set user attributes: [SET
PROPERTY](../../../sql-manual/sql-statements/account-management/SET-PROPERTY)
+- View user attributes: [SHOW
PROPERTY](../../../sql-manual/sql-statements/account-management/SHOW-PROPERTY)
+
+## Other Notes
+
+1. Priority selection of user_identity during login
+
+ As mentioned above, `user_identity` consists of `user_name` and `host`,
but when users log in, they only need to input `user_name`, so Doris matches
the corresponding `host` based on the client's IP to determine which
`user_identity` to use for login.
+
+ If only one `user_identity` can be matched based on the client IP, then
this `user_identity` will undoubtedly be matched. However, when multiple
`user_identity` can be matched, there will be the following priority issues.
+
+ 1. Priority between domain and IP:
+
+ Suppose the following users were created:
+
```sql
- CREATE USER user1@'%' IDENTIFIED BY "12345";
- CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ CREATE USER user1@['domain1'] IDENTIFIED BY "12345";
+ CREATE USER user1@'ip1'IDENTIFIED BY "abcde";
```
- In terms of priority, `'192.%'` takes precedence over `'%'`.
Therefore, when user `user1` attempts to log in to Doris from `192.168.1.1`
using password `'12345'`, the login will be rejected.
- 2. Forgotten Password
+ domain1 is resolved to two IPs: ip1 and ip2.
+
+ In terms of priority, IP takes precedence over domain, so when user
user1 tries to log in to Doris from ip1 using password '12345', it will be
rejected.
+
+ 2. Priority between specific IP and IP range:
+
+ Suppose the following users were created:
+
+ ```sql
+ CREATE USER user1@'%' IDENTIFIED BY "12345";
+ CREATE USER user1@'192.%' IDENTIFIED BY "abcde";
+ ```
+
+ In terms of priority, '192.%' takes precedence over '%', so when user
user1 tries to log in to Doris from 192.168.1.1 using password '12345', it will
be rejected.
+
+2. Forgot password
- If you forget your password and cannot log in to Doris, you can add the
`skip_localhost_auth_check=true` parameter to the FE's configuration file and
restart the FE. This will allow you to log in to Doris from the FE machine
without a password using the `root` user.
+ If you forget your password and cannot log in to Doris, you can add the
skip_localhost_auth_check=true parameter in the FE config file and restart FE,
so you can log in to Doris as root on the FE local machine without a password.
- After logging in, you can use the `SET PASSWORD` command to reset your
password.
+ After logging in, you can reset the password using the SET PASSWORD
command.
- 3. Any user cannot reset the password of the `root` user, except for the
`root` user itself.
+3. No user can reset the root user's password except the root user itself.
- 4. `current_user()` and `user()`
+4. `current_user()` and `user()`
- Users can use `SELECT current_user()` and `SELECT user()` to view
`current_user` and `user`, respectively. `current_user` indicates the identity
used by the current user to pass the authentication system, while `user` is the
actual User Identity of the current user.
+ Users can view `current_user` and `user` through `SELECT current_user()`
and `SELECT user()` respectively. `current_user` represents the identity
through which the current user passed the authentication system, while `user`
is the user's actual User Identity.
- For example:
+ Example:
- Suppose `user1@'192.%'` is created, and then a user named `user1` logs
in to the system from `192.168.10.1`. At this time, `current_user` is
`user1@'192.%'`, and `user` is `user1@'192.168.10.1'`.
+ Suppose we created the user `user1@'192.%'`, then user `user1` from
`192.168.10.1` logged into the system. In this case, `current_user` would be
`user1@'192.%'`, while `user` would be `user1@'192.168.10.1'`.
- All permissions are granted to a specific `current_user`, and the
actual user has all the permissions of the corresponding `current_user`.
+ All permissions are granted to a specific `current_user`, and the actual
user has all the permissions of the corresponding `current_user`.
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
