Merge pull request #3095 from emqx/20250724-sync-r510-to-r60

sync release-5.10 to release-60

Author: id

dir.yaml

@@ -899,12 +899,17 @@
       title_cn: MQTT Guide
       title_ja: MQTT ガイド
       lang: en
-      path: https://www.emqx.com/en/mqtt-guide
-    - title_en: MQTT Guide
-      title_cn: MQTT Guide
-      title_ja: MQTT ガイド
-      lang: ja
-      path: https://www.emqx.com/en/mqtt-guide
+      path: design/mqtt-guide
+      collapsed: true
+      children:
+        - title_en: MQTT Basics
+          title_cn: MQTT Basics
+          title_ja: MQTT Basics
+          path: design/mqtt-basics
+        - title_en: MQTT Advanced
+          title_cn: MQTT Advanced
+          title_ja: MQTT Advanced
+          path: design/mqtt-advanced
     - title_en: MQTT 教程
       title_cn: MQTT 教程
       title_ja: MQTT チュートリアル

en_US/access-control/authn/ldap.md

@@ -13,29 +13,27 @@ Knowledge about [basic EMQX authentication concepts](../authn/authn.md)
 EMQX's LDAP integration includes two distinct authentication methods:
 - **LDAP Bind Authentication**
 
-  EMQX directly uses LDAP binding to authenticate usernames and passwords. When a client connects, EMQX receives the provided username and password, then constructs a Distinguished Name (DN) using the configured `base_dn` and `filter`. It then attempts to bind (log in) to the LDAP server as the client using these credentials. If the bind operation succeeds, the authentication is accepted; otherwise, the connection is rejected.
+   EMQX directly uses LDAP binding to authenticate usernames and passwords. When a client connects, EMQX receives the provided username and password, then constructs a Distinguished Name (DN) using the configured `base_dn` and `filter`. It then attempts to bind (log in) to the LDAP server as the client using these credentials. If the bind operation succeeds, the authentication is accepted; otherwise, the connection is rejected.
 
-  This method relies solely on the existing LDAP user entries and does not require EMQX to retrieve or process any sensitive data like password hashes. It is simple to set up and does not require modifying the LDAP schema.
+   This method relies solely on the existing LDAP user entries and does not require EMQX to retrieve or process any sensitive data like password hashes. It is simple to set up and does not require modifying the LDAP schema.
 
-  This approach is suitable for situations where:
+   This approach is suitable for situations where:
 
-  - User accounts already exist in the LDAP server.
-  - The LDAP schema cannot be changed or extended.
-  - You prefer minimal setup, and the LDAP server handles authentication directly.
+   - User accounts already exist in the LDAP server.
+   - The LDAP schema cannot be changed or extended.
+   - You prefer minimal setup, and the LDAP server handles authentication directly.
 
 - **Local Password Comparison**
 
-  EMQX connects to the LDAP server using the bind account specified by the `username` and `password` configuration options (i.e., the bind DN). It then locates the client’s LDAP entry and retrieves the stored password (usually in a hashed format) from a specific attribute. The provided client password is then compared with the retrieved hash locally within EMQX.
+   EMQX connects to the LDAP server using the bind account specified by the `username` and `password` configuration options (i.e., the bind DN). It then locates the client’s LDAP entry and retrieves the stored password (usually in a hashed format) from a specific attribute. The provided client password is then compared with the retrieved hash locally within EMQX.
 
-  This method provides greater flexibility and control over the authentication process. It supports various password hash algorithms, allows retrieval of additional user attributes, and can be integrated with custom authentication logic or security policies.
+   This method provides greater flexibility and control over the authentication process. It supports more complex validation logic and security strategies, and handles additional user attributes. For example, EMQX can retrieve the user's `isSuperUser` flag while querying the user's password, which means EMQX can determine whether the user has superuser privileges while authenticating, thereby providing different levels of access and operational capabilities based on the user's permission level.
 
-  This approach is suitable for situations where:
+   This approach is suitable for situations where:
 
-  - You need to store or process custom authentication attributes (e.g., `isSuperuser`, ACL rules).
-  - You have permission to configure schemas and data on the LDAP server.
-  - More advanced security or validation logic is required beyond simple LDAP binding.
-
-In both methods, EMQX can retrieve additional attributes such as the `isSuperuser` flag or ACL rules from the LDAP entry, using the `base_dn` and `filter` configuration. These attributes can be used to determine administrative permissions or enforce fine-grained access control. For detailed information, see [Retrieve ACL Rules from LDAP](#retrieve-acl-rules-from-ldap).
+   - You need to store or process custom authentication attributes (e.g., `isSuperuser`, ACL rules).
+   - You have permission to configure schemas and data on the LDAP server.
+   - More advanced security or validation logic is required beyond simple LDAP binding.
 
 ## LDAP Data Schema and Query
 
@@ -151,17 +149,21 @@ directory       /usr/local/etc/openldap/data
 You can configure how to use LDAP for password authentication in the EMQX Dashboard.
 
 1. In the EMQX Dashboard, click **Access Control** -> **Authentication** from the left navigation menu.
+
 2. On the **Authentication** page, click **Create** in the top right corner.
+
 3. Click to select **Password-Based** as **Mechanism**, and **LDAP** as **Backend** to go to the **Configuration** tab, as shown below.
 
-<img src="./assets/authn-ldap.png" alt="authn-ldap"  />
+   <img src="./assets/authn-ldap.png" alt="authn-ldap"  />
 
 4. Follow the instructions below for the configuration:
 
    - Enter the information needed to connect to the LDAP server.
 
-     - **Server**: Specify the server address that EMQX connects to (`host:port`).
+     - **Server**: Specify the server address that EMQX is to connect (`host:port`).
+
      - **Username**: Specifies the account name EMQX uses to bind to the LDAP server (i.e., the bind DN), for example: `cn=root,dc=emqx,dc=io`. This account must have permission to read user entries and is typically the same as the `rootdn` defined in the LDAP configuration file (e.g., `slapd.conf`).
+
      - **Password**: The plaintext password corresponding to the above username, used to complete the bind operation. This value should match the actual password of the `rootpw` defined in the LDAP configuration.
 
    - **Authentication configuration**: Fill in the authentication-related settings.
@@ -170,6 +172,7 @@ You can configure how to use LDAP for password authentication in the EMQX Dashbo
 
      - **Bind Password**: Specifies the password that EMQX uses to authenticate itself to the LDAP server before it can perform any operations or queries. It is referenced through a placeholder `${password}` that will be resolved at runtime with the actual password defined in the configuration option **Password**.
 
+
      - **Base DN**: Specifies the starting point (i.e., base DN) for LDAP search operations. EMQX begins searching for user entries that match the configured filter from this DN. Placeholders such as `${username}` are supported for dynamically constructing the client identity. For more information, see, see [RFC 4511 Search Request](https://datatracker.ietf.org/doc/html/rfc4511#section-4.5.1).
 
        ::: tip
@@ -180,19 +183,17 @@ You can configure how to use LDAP for password authentication in the EMQX Dashbo
 
      - **Password Hash Attribute**: Specifies the attribute representing the user's password, applicable when `Local Password Comparison` is selected as the authentication method. The value of this attribute should follow [RFC 3112](#https://datatracker.ietf.org/doc/html/rfc3112), the supported algorithms are `md5`,  `sha`, `sha256`, `sha384`, `sha512`, and `ssha`.
 
+
      - **Is Superuser Attribute**: Identifies the attribute that indicates whether a user is a superuser, applicable when `Local Password Comparison` is selected as the authentication method.  The value of this attribute should be in boolean, if absent is equal to `false`.
-   
-   - **Precondition**: A [Variform expression](../../configuration/configuration.md#variform-expressions) used to control whether this LDAP authenticator should be applied to a client connection. The expression is evaluated against attributes from the client (such as `username`, `clientid`, `listener`, etc.). The authenticator will only be invoked if the expression evaluates to the string `"true"`. Otherwise, it will be skipped. For more information about the precondition, see [Authentication Preconditions](./authn.md#authentication-preconditions).
-   
+
+     - **Precondition**: A [Variform expression](../../configuration/configuration.md#variform-expressions) used to control whether this LDAP authenticator should be applied to a client connection. The expression is evaluated against attributes from the client (such as `username`, `clientid`, `listener`, etc.). The authenticator will only be invoked if the expression evaluates to the string `"true"`. Otherwise, it will be skipped. For more information about the precondition, see [Authentication Preconditions](./authn.md#authentication-preconditions).
+
    - **Enable TLS**: Turn on the toggle switch if you want to enable TLS. For more information on enabling TLS, see [Network and TLS](../../network/overview.md).
-   
-   - **Filter**: Defines the criteria for the LDAP query. The filter sets conditions that an entry must meet to be considered a match.
-     The syntax of the filter follows [RFC 4515](#https://www.rfc-editor.org/rfc/rfc4515) and also supports placeholders.
-   
+   - **Filter**: Defines the criteria for the LDAP query. The filter sets conditions that an entry must meet to be considered a match. The syntax of the filter follows [RFC 4515](#https://www.rfc-editor.org/rfc/rfc4515) and also supports placeholders.
    - **Advanced Settings**: Set the concurrent connections and waiting time before a connection is timed out.
      - **Connection Pool size** (optional): Input an integer value to define the number of concurrent connections from an EMQX node to LDAP. Default: `8`.
      - **Query Timeout** (optional): Specify the waiting period before EMQX assumes the query is timed out. Default: `5` seconds.
-   
+
 5. After you finish the settings, click **Create**.
 
 ## Configure LDAP Authentication via Configuration Items

en_US/access-control/authz/mongodb.md

@@ -12,11 +12,11 @@ Knowledge about [basic EMQX authorization concepts](./authz.md)
 
 MongoDB authorizer supports storing authorization rules as MongoDB documents. Users need to provide a query template to make sure that the result contains the following fields:
 
-* `permission` value specifies the applied action if the rule matches. It should be one of `deny` or `allow`.
-* `action` value specifies the request for which the rule is relevant. Should be one of `publish`, `subscribe`, or `all`.
-* `topic` value specifies the topic filter for topics relevant to the rule. Should be a string that supports wildcards and [topic placeholders](./authz.md#topic-placeholders).
-* `qos` (Optional) value specifies the QoS levels that the current rule applies to. Value options are `0`, `1`, `2`. It can also be a number array to specify multiple QoS levels. The default is all QoS levels.
-* `retain` (Optional) value specifies whether the current rule supports retained messages. Value options are `0`, `1,` or `true`, `false`. The default is to allow retained messages.
+* `permission`: Specifies the applied action if the rule matches. Available values are `deny` or `allow`.
+* `action`: Specifies the request for which the rule is relevant. Possible values are `publish`, `subscribe`, or `all`.
+* `topic` / `topics`: Specifies one or a list of topics the rule applies to. Supports topic filters and [topic placeholders](./authz.md#topic-placeholders).
+* `qos` (optional): Specifies the QoS levels that the current rule applies to. Value options are `0`, `1`, `2`. It can also be a number array to specify multiple QoS levels. The default is all QoS levels.
+* `retain` (optional): Indicates whether the rule allows publishing retained messages. Value options are `0`, `1,` or `true`, `false`. By default, retained messages are allowed.
 
 Deny client with username `emqx_u` to publish to topic `t/1` with QoS 1:
 
@@ -50,7 +50,7 @@ When there is a significant number of users in the system, optimize and index th
 
 For this MongoDB data schema, the corresponding Dashboard configuration parameter is **Filter**: `{ username = "${username}" }`.
 
-## Configurate with Dashboard
+## Configure with Dashboard
 
 You can use EMQX Dashboard to configure how to use MongoDB for user authorization.
 

en_US/changes/all-changes-ee.md

@@ -69,6 +69,8 @@ The release notes page for EMQX Enterprise provides a comprehensive and detailed
 
 ## v4.4
 
+- [4.4.32](./changes-ee-v4.md#_4-4-32): 2025-07-25
+- [4.4.31](./changes-ee-v4.md#_4-4-31): 2025-07-15
 - [4.4.30](./changes-ee-v4.md#_4-4-30): 2025-06-20
 - [4.4.29](./changes-ee-v4.md#_4-4-29): 2025-03-07
 - [4.4.28](./changes-ee-v4.md#_4-4-28): 2025-01-23

en_US/changes/changes-ee-v4.md

@@ -1,5 +1,71 @@
 # EMQX Enterprise Version 4
 
+## e4.4.32
+
+*Release Date: 2025-07-25*
+
+### Enhancements
+
+- Support for placeholders in HTTP headers in the HTTP AUTH/ACL module.
+
+  The HTTP AUTH/ACL module now supports using placeholders (such as `%u`, `%c`, etc.) in the values of HTTP request headers, allowing dynamic insertion of client information.
+
+- Optimized default Erlang VM parameters.
+
+  - `+sbwt none +sbwtdcpu none +sbwtdio none`: Disables scheduler busy-waiting to reduce CPU consumption.
+  - `+sbt db`: Configures scheduler threads to use the default binding strategy to CPU cores.
+  - `+zdbbl 32768`: Increases the buffer size for distributed channels.
+
+- Periodic global garbage collection (GC) is disabled by default.
+
+  The default value of the `node.global_gc_interval` configuration is now set to `Disabled`.
+
+### Bug Fixes
+
+- Fixed an issue where Kafka resources failed to authenticate using the "SCRAM_SHA_256" method.
+
+## e4.4.31
+
+*Release Date: 2025-07-15*
+
+### Enhancements
+
+- Improved performance of the Username Quota module.
+
+  When the Username Quota feature is enabled in a multi-node cluster, EMQX nodes need to frequently synchronize username state (i.e., mappings between usernames and client IDs) with other nodes, which can cause performance overhead. This version introduces batch synchronization, reducing CPU usage.
+
+- Added “Refresh Username Interval” configuration option.
+
+  To prevent inconsistencies in the username quota table across nodes under certain extreme conditions, this version adds a scheduled refresh mechanism. EMQX will periodically fetch username status from other nodes to update the local quota table. The default interval is 15 minutes, and the minimum configurable value is 30 seconds.
+
+- Added “Send Undefined Properties” option to the Republish action.
+
+  This option controls whether undefined MQTT properties and user properties are included in republished messages. When enabled, such properties are added with the string `"undefined"` as their value. When disabled, they will be omitted from the message.
+
+- Improved HTTP API stability under high-latency network conditions.
+
+  Parts of the HTTP API implementation that relied on RPC have been refactored to use `gen_rpc`, avoiding contention for Erlang’s distributed RPC channels and reducing the risk of blocking.
+
+- Optimized the query performance of the built-in database authentication (`auth_mnesia`).
+
+  Previously, the query performance of the built-in authentication database would degrade as the number of records increased, leading to high CPU consumption during periods of high-frequency or concurrent client logins. After the optimization, query performance is no longer affected by the number of records, resulting in improved authentication efficiency and overall system stability.
+
+### Bug Fixes
+
+- Fixed inconsistent routing tables or client global registries after cluster healing.
+
+  In cases where a network partition causes the cluster to split into overlapping subgroups, simply restarting the minority partition might not fully restore consistency. This could lead to issues such as messages not being routed to subscribers on other nodes, or failure to kick out clients via the HTTP API.
+
+  This version adjusts the cluster healing logic by ensuring that all nodes in both the minority partition and the overlapping group are restarted, ensuring consistency is restored across the cluster.
+
+- Fixed ETS memory leak caused by exceptions in HTTP API calls.
+
+  Resolved an issue where exceptions during certain HTTP API calls could result in memory leaks in ETS tables.
+
+- Fixed an issue where listeners could not be added to gateway modules via the Dashboard.
+
+  Previously, after creating a protocol gateway module, adding a listener through the module update interface had no effect. Affected protocols included CoAP, GB/T 32960, JT/T 808, LwM2M, MQTT-SN, STOMP, and TCP.
+
 ## e4.4.30
 
 *Release Date: 2025-06-20*

en_US/deploy/cluster/assets/EMQX_Mria_architecture.png

@@ -2,5 +2,6 @@
 
 This chapter serves as a comprehensive guide to understanding the essential components and concepts of MQTT and EMQX. In this chapter, you will learn the fundamental knowledge and practical insights about the MQTT protocol and the EMQX broker. Let's take a closer look at what you can expect to learn:
 
-- [MQTT Guide](https://www.emqx.com/en/mqtt-guide) provides all you need to learn about MQTT.
-- [Design and Implementation](../design/overview.md) introduce the design principles of some key EMQX features.
+- [MQTT Guide](./mqtt-guide.md) provides all you need to learn about MQTT, from basics to advanced.
+- [Design and Implementation](../design/overview.md) introduces the design principles of some key EMQX features.
+