All Products
Search
Document Center

ApsaraVideo Live:Access control

Last Updated:May 20, 2025

Streaming domains implement various access control policies, including URL signing, Referer-based hotlink protection, IP address blacklist and whitelist, protocol prohibition, region blocking, and remote authentication, to effectively prevent unauthorized access and illegal use, and enhance the security and user experience of live streaming services. Users can select and configure appropriate access control policies based on their business and security requirements to ensure the security and stable operation of live streaming resources.

Overview

Access control for streaming domains is an important means to ensure resource security and prevent unauthorized use, mainly including the following methods:

  • URL signing: URL signing can effectively prevent issues that Referer-based hotlink protection cannot fully protect against, ensuring the legitimacy of each request.

  • Referer-based hotlink protection: By configuring custom blacklists/whitelists and rule content through Referer-based hotlink protection, you can allow or reject playback requests to protect live streaming content.

  • IP address blacklist and whitelist: IP address blacklists and whitelists can restrict or allow access from specific IP addresses, enabling identification and filtering of visitor identities.

  • Protocol prohibition: By restricting the playback protocols of the current domain, once enabled, the corresponding playback protocols under that domain will be unavailable, and playback address requests generated by the prohibited protocol will be rejected.

  • Region blocking: Through playback region management configuration, you can specify blacklists or whitelists for playback regions to manage the playback regions of the current domain.

  • Remote authentication: Remote authentication can forward user requests to a specified authentication server for verification, further enhancing the flexibility and security of access control.

URL signing

How it works

ApsaraVideo Live works with your live streaming server to implement URL signing to protect live streaming resources against hotlinking in a more secure and reliable manner.

  1. A live streaming server of a user provides a signed URL that contains authentication information.

  2. Stream ingest or streaming users send a request to ApsaraVideo Live by using the signed URL.

  3. ApsaraVideo Live verifies the authentication information in the signed URL to determine whether the request is valid. ApsaraVideo Live processes valid requests and rejects invalid requests.

Important

After your request URL is authenticated by ApsaraVideo Live, special characters in the URL, such as = and +, are escaped.

For more information about the scenarios, composition, and principles of URL signing, see Authentication of ingest and streaming URLs.

Configure URL signing

  1. Log on to the ApsaraVideo Live console.
  2. In the left-side navigation pane, click Domain Names. The Domain Management page appears.

  3. Find the streaming domain that you want to configure and click Domain Settings in the Actions column.

  4. Click Live Management > Access Control.

  5. Click the URL Signing tab and click Change Settings.

    修改配置

    Note

    When you add a domain name for the first time, URL Signing is enabled by default. You can Modify the configuration only when URL signing is enabled.

  6. Configure URL signing and click OK.

    URL鉴权配置

    The following table describes the parameters.

    Parameter

    Description

    Authentication Type

    ApsaraVideo Live streaming domains support only Authentication Type A to protect resources on the origin server.

    Note

    If URL signing fails, HTTP status code 403 is returned. In this case, you must recalculate the signature.

    • Invalid MD5 values

      Example: X-Tengine-Error:denied by req auth: invalid md5hash=de7bfdc915ced05e17380a149bd760be

    • Invalid timestamps

      Example: X-Tengine-Error:denied by req auth: expired timestamp=1439469547

    Primary Key

    After you add a domain name, ApsaraVideo Live generates a random primary key for the domain name. You can view the primary key on the URL Signing page. To go to the URL Signing page, choose Domain Names in the left-side navigation pane, find the domain name that you want to configure, and click Domain Configuration > Access Control > URL Signing. You can also change the primary key for the selected authentication type.

    Secondary Key

    Specify the secondary key for the selected authentication method.

    Note
    • The primary key and secondary key have the same effect. The secondary key is mainly used for smooth replacement.

    • If the primary key is replaced, the signed URL generated by using the primary key becomes invalid. If you write the old primary key to the secondary key during replacement, the secondary key can continue to provide services instead of the primary key.

    Validity Period

    The validity period indicates the period of time during which URL signing is valid for stream ingest or playback. Live stream ingest and playback are long-connection behaviors. Established connections are not terminated when the validity period expires, but new requests fail due to expiration. The default validity period for a new domain name is one day (1,440 minutes). You can customize the validity period. The minimum validity period is 1 minute, and there is no upper limit.

Disable URL signing

Note
  • Before you disable URL Signing, understand the risks of unauthorized access and sign the Disclaimer Agreement for Disabling URL Signing.

  • After you disable URL Signing, you can generate permanently valid stream ingest or streaming URLs.

  1. On the URL Signing tab, click Sign Agreement.

  2. In the Sign Agreement dialog box, select the check box and click Sign Agreement.

  3. After the Disclaimer Agreement for Disabling URL Signing is signed, click OK.

  4. Turn off the URL Signing switch. After URL signing is disabled, you cannot encrypt URLs by setting cryptographic keys.

Referer-based hotlink protection

How it works

The hotlink protection feature identifies the source of requests based on the Referer mechanism of the HTTP protocol and supports blacklist or whitelist mechanisms. ApsaraVideo Live nodes filter visitor identities based on preset lists. Users who meet the rules can access resources, while users who do not meet the rules receive a 403 response.

Note
  • Hotlink protection is optional, and is disabled by default.

  • The blacklist and whitelist are mutually exclusive. You can enable only one of them at the same time.

  • When you configure a Referer blacklist or whitelist, wildcard domain names can be automatically added. For example, if you enter example.com, the configuration that takes effect is *.example.com. All child domain names take effect.

  • You can specify whether to allow requests with an empty Referer header to access your resources. If you allow such requests, users can directly access the resources by entering the URL into the address bar of a browser.

    • In most cases, mobile clients cannot obtain the Referer header. By default, requests with an empty Referer header are allowed. If you do not allow requests with an empty Referer header, you can use ApsaraVideo Player SDK to configure the Referer header for requests on mobile clients.

    • When you do not allow requests with an empty Referer header, you must configure HTTPS Secure Acceleration and enable force redirect to HTTPS (HTTP > HTTPS). Some browsers remove the Referer header when processing HTTP resources in HTTPS requests, which causes access failures.

Procedure

  1. Log on to the ApsaraVideo Live console.
  2. In the left-side navigation pane, click Domain Names. The Domain Management page appears.

  3. Find the streaming domain that you want to configure and click Domain Settings in the Actions column.

  4. Click Streaming Management > Access Control.

  5. Click the Referer-based Hotlink Protection tab and turn on Referer-based Hotlink Protection.

    开启

  6. Configure Type and Referrers, and click OK.

    配置防盗链

    The following table describes the types of Referer-based hotlink protection.

    Type

    Description

    Blacklist

    Requests from domain names that are included in the blacklist cannot access your resources.

    Whitelist

    Only requests from domain names that are included in the whitelist can access your resources.

IP address blacklist and whitelist

How it works

  • If you configure an IP address blacklist, IP addresses in the blacklist are not allowed to access the accelerated domain name.

  • If you configure an IP address whitelist, only IP addresses in the whitelist can access the accelerated domain name.

Note
  • IP address blacklist and whitelist support IPv6 addresses. Letters in IPv6 addresses must be uppercase. Examples: 2001:DB8:0:23:8:800:200C:417A and 2001:0DB8:0000:0023:0008:0800:200C:417A. You cannot shorten an IPv6 address by using the two-colon (::) notation. For example, 2001:0DB8::0008:0800:200C:417A is invalid.

  • IP address blacklist and whitelist support CIDR blocks. For example, in the 192.168.0.0/24 CIDR block, /24 indicates that the first 24 bits in the subnet mask are network bits. The remaining 8 bits are host bits. The number of host bits is calculated based on the following formula: 32 - 24 = 8. The subnet can accommodate up to 254 hosts. The number of hosts is calculated based on the following formula: 2^8 - 2 = 254. Therefore, 192.168.0.0/24 indicates IP addresses from 192.168.0.1 to 192.168.0.254.

Procedure

  1. Log on to the ApsaraVideo Live console.
  2. In the left-side navigation pane, click Domain Names. The Domain Management page appears.

  3. Find the streaming domain that you want to configure and click Domain Settings in the Actions column.

  4. Choose Streaming Management > Access Control.

  5. Click the IP Blacklist or Whitelist tab and turn on IP Blacklist or Whitelist.

    开启黑白名单

  6. Configure List Type and Rule, and click OK.

    配置黑白名单-chs

    Type

    Description

    Blacklist

    Requests from domain names that are included in the blacklist cannot access your resources.

    Whitelist

    Only requests from the domain names that are included in the whitelist can access your resources.

Protocol prohibition

How it works

The protocol prohibition feature prohibits streams of specified protocols under a specific streaming domain. The streaming domain can be a main streaming domain or sub-streaming domain. After you prohibit a protocol for a streaming domain, you cannot use the corresponding streaming URL over the protocol for playback.

In addition to the console, you can also call the BatchSetLiveDomainConfigs operation and pass the alilive record in the Functions parameter. For more information, see BatchSetLiveDomainConfigs.

Procedure

  1. Log on to the ApsaraVideo Live console.

  2. In the left-side navigation pane, click Domain Names. The Domain Management page appears.

  3. Find the streaming domain that you want to configure and click Domain Settings in the Actions column.

  4. Choose Streaming Management > Access Control.

  5. Click the Protocol Prohibition tab, select the protocol that you want to prohibit, and turn on the prohibition feature.

    禁播

Region blocking

How it works

The region blocking feature identifies the source regions of client access requests, blocks access from specific regions, or allows access only from specific regions, solving issues such as malicious requests from certain regions and content distribution copyright.

Note
  • The HTTP Live Streaming (HLS), Real-Time Messaging Protocol (RTMP), Flash Video (FLV), and Real-Time Streaming (RTS) protocols for streaming are supported.

  • You can configure region blocking at the domain name level or at the stream level. If you add a region to a domain-level whitelist and a stream-level blacklist, the region is blocked at the stream level. If you add a region to a domain-level blacklist and a stream-level whitelist, the region is blocked at the domain name level.

  • You can configure both Domain-level Region Blocking and Stream-level Region Blocking at the same time. If there is a conflict between the blacklist and whitelist of the two, the configured blacklist takes precedence for blocking access to regions.

Configure domain-level region blocking

  1. Log on to the ApsaraVideo Live console.

  2. In the left-side navigation pane, click Domain Names. The Domain Management page appears.

  3. Find the streaming domain that you want to configure and click Domain Settings in the Actions column.

  4. Choose Streaming Management > Access Control.

  5. On the Region Blocking tab, turn on the Domain-level Region Blocking switch, and select Blocking Type and Blocked Regions.

    Parameter

    Description

    Blocking Type

    • Blacklist: All requests from the regions in the blacklist are blocked from accessing resources in the streaming domain.

    • Whitelist: Only requests from the regions in the whitelist are allowed to access resources in the streaming domain.

    The blacklist and whitelist are mutually exclusive. Only one of them can take effect at a time.

    Blocked Regions

    Add regions to the blacklist or whitelist.

  6. Click OK to complete the configuration.

Configure stream-level region blocking

  1. Log on to the ApsaraVideo Live console.

  2. In the left-side navigation pane, click Domain Names. The Domain Management page appears.

  3. Find the streaming domain that you want to configure and click Domain Settings in the Actions column.

  4. Choose Streaming Management > Access Control.

  5. Click the Region Blocking tab and click Add under Stream-level Region Blocking.添加封禁..png

    Parameter

    Description

    AppName

    The name of the application to which the live stream belongs.

    Note

    The name can be up to 256 characters in length and can contain digits, letters, hyphens (-), underscores (_), and equal signs (=). The blocking rule takes effect only if the value of this parameter is the same as the application name specified in the streaming URL.

    StreamName

    The name of the live stream.

    Note

    The name can be up to 256 characters in length and can contain digits, letters, hyphens (-), underscores (_), and equal signs (=). The blocking rule takes effect only if the value of this parameter is the same as the stream name specified in the streaming URL.

    Blocking Type

    • Blacklist: All requests from the regions in the blacklist are blocked from accessing resources in the streaming domain.

    • Whitelist: Only requests from the regions in the whitelist are allowed to access resources in the streaming domain.

    Note

    The blacklist and whitelist are mutually exclusive. Only one of them can take effect at a time.

    Blocked Regions or Allowed Regions

    The regions in the blacklist or whitelist.

    Expiration Time

    The time when the blocking rule expires. By default, the expiration time of the rule is seven days from now. Modify this parameter based on your business requirements.

  6. Click OK to complete the configuration.

  7. View the stream-level region blocking rule. After you add a stream-level region blocking rule, you can refresh the rule list to view the rule status. You can query rules based on AppName, StreamName, and the type of the rule (blacklist or whitelist).

Remote authentication

How it works

Both remote authentication and URL signing protect live streaming resources, ensuring that only successfully authenticated users can access these resources. The two methods have the following technical implementation differences:

  • URL signing: Users distribute the authentication rules of the domain name to the live center, and the live center completes the entire data interaction process of authentication.

  • Remote authentication: Users have their own separately configured authentication server. After the live center receives a user request, it needs to forward the user request to the authentication server to complete the authentication. The authentication server is established and managed by the user. Remote authentication does not support the HLS protocol.

The data interaction process of the remote authentication feature is as follows:

image

Number

Interaction description

1

The user initiates a resource access request to the live center, with authentication parameters included in the request.

2

The live center receives the user request and forwards it directly (or after processing according to specified rules) to the authentication server.

3

The authentication server provides an authentication result based on the authentication parameters in the user request and returns it to the live center.

4

The live center performs the corresponding action based on the authentication result returned by the authentication server and returns the corresponding data to the user.

  • Example 1: If authentication is successful, the live center begins normal cached data access interaction with the user.

  • Example 2: If authentication fails, the live center returns HTTP status code 403 to the user.

  • Example 3: If authentication times out, the live center performs the default action for authentication timeout, which is to allow or reject the user request.

Procedure

  1. Log on to the ApsaraVideo Live console.
  2. In the left-side navigation pane, click Domain Names. The Domain Management page appears.

  3. Find the streaming domain that you want to configure and click Domain Settings in the Actions column.

  4. Choose Streaming Management > Access Control.

  5. Click the Remote Authentication tab, turn on the Remote Authentication switch, and configure the remote authentication parameters according to the interface prompts.

    Note

    After you enable remote authentication, all user requests are redirected to the authentication server. If many requests are sent to POPs, ensure that the authentication server can handle traffic spikes without compromising performance.

    Parameter

    Description

    Authentication Server Address

    The address of the authentication server. This address must be publicly accessible. The system checks whether the format and value of the address that you enter are valid. You can specify a fixed URL or a variable concatenated URL.

    • Fixed URL: The HTTP and HTTPS protocols are supported. The value cannot contain 127.0.0.1 and localhost, which are invalid local addresses. Sample formats:

      • http(s)://example.aliyundoc.com/auth

      • http(s)://192.0.2.1/auth

    • Variable concatenated URL: You can construct a signed URL by concatenating variables and then use the URL as the address of the authentication server. For more information about the rules for variable concatenated URLs, see Variable concatenated URL.

    Pass-through Request URL Parameters

    Specify the URL parameters that you want the authentication server to check. You can select Pass Through Specified Parameters, Do Not Pass Through Specified Parameters, or Do Not Pass Through Request URL Parameters.

    Note

    If you select Pass Through Specified Parameters or Do Not Pass Through Specified Parameters, enter the specified parameters that you want to pass through in the input box below. Separate multiple parameters with commas (,). Example: key1,key2,key3.

    HTTP Status Code For Authentication Result

    The HTTP status code that the authentication server returns to the live center. You can select one of the following options:

    • HTTP Status Code For Successful Authentication: After you select this option, enter a custom HTTP status code for successful authentication in the input box below. The live center allows user requests only when the authentication server returns this HTTP status code. The live center blocks user requests when the authentication server returns other HTTP status codes.

      If you set the HTTP status code to 200, the authentication server returns the HTTP 200 status code to POPs for client requests that pass the authentication.

    • HTTP Status Code For Failed Authentication: After you select this option, enter a custom HTTP status code for failed authentication in the input box below. The live center blocks user requests only when the authentication server returns this HTTP status code. The live center allows user requests when the authentication server returns other HTTP status codes.

      If you set the HTTP status code to 403, the authentication server returns the HTTP 403 status code to POPs for client requests that fail the authentication.

    Authentication Duration (Seconds)

    The period of time that starts when the live center initiates authentication and ends when the live center receives the authentication result from the authentication server.

    Valid values: integers from 0 to 30.

    Number Of Authentication Timeout Retries

    The number of times that the authentication server retries authentication if the specified authentication duration is exceeded. After the number of retries reaches the specified value, the action that you specify for authentication timeout is performed. You can select Allow or Reject.

    Action After Authentication Timeout

    The action that you want to perform on requests when the data interaction between the live center and authentication server times out. You can select Allow or Reject. The differences are as follows:

    • Allow: If authentication times out, the live center directly allows user requests.

    • Reject: If authentication times out, the live center rejects user requests and returns the HTTP status code for failed authentication (such as HTTP status code 403) to users.

    Asynchronous Authentication (Advanced Configuration)

    If you enable asynchronous authentication, a stream can be played without the need to wait for the authentication result. If the result that is returned at a later point in time indicates failed authentication, the playback is interrupted. This helps prevent the issue of increased first frame duration that is caused by the synchronization of the authentication result.

  6. Click OK to complete the parameter configuration.

    After you successfully configure remote authentication, you can modify the current configuration or disable remote authentication on the Remote Authentication tab.

Variable concatenated URL

You can construct a signed URL by concatenating variables and then use the URL as the address of the authentication server. The following table describes the variables.

Type

Description

Numeric variables

Numeric variables such as ${1} and ${2} are used to reference parts before ? in a stream ingest or streaming URL.

For example, if the stream ingest URL is rtmp://domain.aliyundoc.com/appname/streamname?token=1&name=xr, then ${1}=appname and ${2}=streamname.

Alphabetic variables

Alphabetic variables such as ${arg_token} and ${arg_name} are used to reference parts after ? in a stream ingest or streaming URL.

For example, if the stream ingest URL is rtmp://domain.aliyundoc.com/appname/streamname?token=1&name=xrc, then ${arg_token}=1 and ${arg_name}=xrc.

Custom variables

Custom variables start with the udv_ prefix. Currently, custom variables support ${udv_host} and ${udv_ip}, which are used to reference the host and the IP address of the stream ingest client.

ngx variables

All ngx.var.* variables can be directly referenced. For example, ${args} can reference ngx.var.args.

All values referenced through variables are processed by the URL escape function ngx.escape_uri when concatenating the authentication address to avoid ambiguity caused by special characters.

Stream name variables

You can add variables in the format of videoname=${stream_name}. ${stream_name} is replaced with the stream name in the playback request.

Note

If the stream ingest or streaming URL is rtmp://domain.aliyundoc.com/app/stream?token=***&name=xrc.

The address of the authentication server is configured as http://auth.aliyundoc.com/?app=${udv_host}&streamname=${2}&appname=${1}&token=${arg_token}.

The actual authentication address is http://auth.aliyundoc.com/?app=domain.aliyundoc.com&streamname=stream&appname=app&token=***.