How to manage CDN configurations for cloud storage-Enterprise Mobile Application Studio(EMAS)-阿里云帮助中心

Procedure

Log on to the EMAS console, select Serverless, and click Enter.
In the navigation pane on the left, choose Cloud Storage.
Click the CDN Configuration tab.
Click Edit Configuration to configure Cross-origin validation, URL signing, Hotlink protection, IP blacklists and whitelists, or User-Agent blacklists and whitelists.
After you complete the configuration, click Save.

Configure cross-origin validation

To share or access resources across domains, you can specify cross-origin rules to validate requests.

Parameter	Description
Cross-origin rule	If you set this parameter to "", the `Access-Control-Allow-Origin:` header is always returned, regardless of whether the user request contains the `Origin` parameter or what its value is. The cross-origin resource sharing response header value is set to a single value or multiple comma-separated values. If the value of the Origin header in a request exactly matches any set value, the response includes the corresponding cross-domain header. If there is no exact match, the response does not include a cross-domain header. If you set this parameter to a wildcard domain name, the system checks whether the Origin value in the request header matches the domain name.
Cross-origin validation	Enable: When enabled, CDN points of presence (POPs) perform cross-origin validation on user requests based on the cross-origin rules and return the `Access-Control-Allow-Origin` value based on the validation result. Disable: When disabled, CDN POPs do not validate the Origin header in user requests. They only return the configured `Access-Control-Allow-Origin` value. Note When cross-origin validation is enabled, if a domain name in the Response header value contains a hyphen (`-`), you must escape the hyphen before you configure the rule. Escape the hyphen (`-`) as `%-`. For example: Original response header value: `http://doc.aliyun-example.com`. Escaped response header value: `http://doc.aliyun%-example.com`

Configure URL signing

URL signing adds authentication to specific URLs based on a signing method. You can configure validation for the encrypted string and timestamp in the signed URL. This protects your site's resources from being downloaded or used by unauthorized sites. URL signing provides higher security than hotlink protection and is suitable for files that require a high level of security.

Note

For more information about how URL signing works, see the CDN documentation.
You can calculate the signature based on the authentication method. You can also directly obtain the signed URL using the ListFile management API or the file.info client SDK.

Parameter	Description
Authentication type	Alibaba Cloud CDN provides three types of signing methods. You can select an authentication type based on the format of the encrypted URL to protect your origin resources. The URL signing types are: Type A signing Type B signing Type C signing Note A URL signing error returns a 403 error code. MD5 calculation errors Example: `X-Tengine-Error:denied by req auth: invalid md5hash=de7bfdc915ced05e17380a149bd760be` Timestamp-related errors Example: `X-Tengine-Error:denied by req auth: expired timestamp=1439469547`
Key	The key used for signature calculation.
Validity period of signed URL	The validity period of the signed URL configured for the CDN. Users can access the CDN within this period. After this period, the authentication fails. Unit: seconds Range: 1 to 31536000 Default value: 1800 (30 minutes) Example: The signing server generates a signed URL at 15:00:00 on 2020-08-15 (UTC+8). The validity period of the signed URL on the CDN is 1800 seconds. The signed URL expires at 15:30:00 on 2020-08-15 (UTC+8).

Configure hotlink protection

You can configure a Referer blacklist or whitelist based on the Referer header of an access request. This feature identifies and filters visitors to restrict access to your CDN resources and prevents other sites from hotlinking to your resources.

Note

For more information, see Hotlink protection.

Parameter		Description
Referer type		Blacklist Domain names in the blacklist cannot access the current resource. Whitelist Only domain names in the whitelist can access the current resource. Domain names outside the whitelist cannot access the current resource. Note Blacklists and whitelists are mutually exclusive. You can select only one type at a time.
Rules		You can add multiple Referer entries. Separate them with line breaks. You can use an asterisk () as a wildcard character. For example, if you configure `.developer.aliyundoc.com`, it matches domain names such as `image.developer.aliyundoc.com` and `video.developer.aliyundoc.com`. Note The total length of the hotlink protection rules cannot exceed 60 KB.
Advanced configuration	Allow access to the resource URL directly from the browser's address bar	If you select this option, CDN POPs allow users to access the current resource if the Referer field in the request is empty or missing, such as for browser requests. This applies to both Referer blacklists and whitelists.
	Exact match	Whitelist: Use exact match mode to control whether the domain names in the whitelist must be an exact match. If you select Exact match: Supports exact match. If you enter `example.com` in the whitelist, it matches `example.com`. If you enter `ab.example.com` in the whitelist, it matches `a<any_string>b.example.com`. Does not support suffix match. If you do not select Exact match: Does not support exact match. Supports suffix match. If you enter `example.com` in the whitelist, it matches `example.com` and `<any_string>.example.com`. If you enter `ab.example.com` in the whitelist, it matches `a<any_string>b.example.com` and `<any_string>.a<any_string>b.example.com`. Blacklist: Use exact match mode to control whether the domain names in the blacklist must be an exact match. If you select Exact match: Supports exact match. If you enter `example.com` in the blacklist, it matches `example.com`. If you enter `ab.example.com` in the blacklist, it matches `a<any_string>b.example.com`. Does not support suffix match. If you do not select Exact match: Does not support exact match. Supports suffix match. If you enter `example.com` in the blacklist, it matches `example.com` and `<any_string>.example.com`. If you enter `ab.example.com` in the blacklist, it matches `a<any_string>b.example.com` and `<any_string>.a<any_string>b.example.com`.

Configure IP blacklists and whitelists

You can configure an IP blacklist or whitelist based on the source IP address of an access request. This feature identifies and filters visitors to restrict access to your CDN resources and helps prevent issues such as malicious IP address abuse and attacks.

Note

For more information, see IP blacklists and whitelists.

Parameter

Description

List type

The IP list types are:

Blacklist
IP addresses in the blacklist cannot access any resources under the accelerated domain name.
Whitelist
Only IP addresses in the whitelist can access resources under the accelerated domain name. All other IP addresses are denied access.

Rules

Enter an IP address block (for example, 192.168.0.0/24) or an IP address (for example, 192.168.0.1). Entries cannot be repeated. Both IPv6 and IPv4 addresses are supported. To configure multiple IP addresses, separate them with line breaks.

IPv6: You can configure a maximum of about 700 IPv6 addresses. Both IP blacklists and whitelists support IPv6 addresses. The letters in the addresses are not case-sensitive. For example, FC00:AA3:0:23:3:300:300A:1234 or fc00:0aa3:0000:0023:0003:0300:300a:1234. The `::` abbreviation for IPv6 addresses is not supported. For example, FC00:0AA3::0023:0003:0300:300A:1234 is not supported. You can enter IP address blocks, such as FC00:0AA3:0000:0000:0000:0000:0000:0000/48.
IPv4: You can configure a maximum of about 2000 IPv4 addresses.
The total length of the IP address string cannot exceed 30 KB.

Configure User-Agent blacklists and whitelists

The User-Agent header identifies the client that sends an access request. If you want to specify which clients can access your resources, you can configure a User-Agent blacklist or whitelist. This feature identifies and filters visitors to ensure that only allowed clients can access your resources.

Note

For more information, see User-Agent blacklists and whitelists.

Parameter

Description

List type

The User-Agent list types are:

Blacklist
If the User-Agent field in an HTTP request header matches an entry in the blacklist, the user cannot access any resources under the accelerated domain name.
Whitelist
Users can access resources under the accelerated domain name only if the User-Agent field in the HTTP request header matches an entry in the whitelist.

Rules

When you configure the User-Agent field, use a vertical bar (|) to separate multiple values. Wildcard characters (*) are supported. For example: *curl*|*IE*|*chrome*|*firefox*.

Note

To control access for user requests that contain a User-Agent request header with an empty value, you can use the parameter this-is-empty-ua to indicate that the User-Agent value is empty.
- For a whitelist: If a rule contains this-is-empty-ua, it allows requests that include a User-Agent header with an empty value.
- For a blacklist: If a rule contains this-is-empty-ua, it rejects requests that include a User-Agent header with an empty value.
User-Agent blacklist and whitelist do not support access control for requests that do not contain a User-Agent header. You can use EdgeScript to implement this functionality (for more information, see EdgeScript), or fill in the information to request a backend configuration.