one hundred and seven
Time stamp anti-theft chain

Operating Instructions

Log in to the console ->CDN ->Domain name management ->Configuration ->Access control

Timestamp immobilizer modification configuration

Timestamp anti leech: it is off by default. When it is on, two sets of available keys will be generated at the same time. The user needs to configure the key into your URL in the code according to the document description, then check the format, and then confirm that it is on; You can also customize the key input. It supports the input of an alternate key and cannot be the same as the primary key; At the same time, you need to enter the check URL to ensure the normal availability of the authentication service, so as not to affect the service.

Algorithm description

The time stamp based anti leech is to sign the time related string, and pass the time and signature to the CDN server in a certain way as the judgment basis. The CDN edge node judges whether the visiting URL has access rights according to the agreed algorithm.

Pass and execute the next step; If not, respond to HTTP status code 403.

If the referer, UA security chain and time stamp security chain are configured at the same time, one of them does not meet the conditions, that is, it does not pass, and 403 is responded.

Signature parameters

  • T: URL expiration time. It is expressed in hexadecimal lowercase form of unix_time. as 2016-08-01 00:00:00 –> 1438358400 –> 55bb9b80
  • Key: When the timestamp immobilizer is enabled, you can use one of the following: (Console ->CDN ->Domain Name Management ->Access Control ->Timestamp immobilizer). It can also be generated by its own algorithm.
  • Path: The path part of the URL to access the resource, for example, the URL to access is //xxx.yyy.com/DIR1/dir2/vodfile.mp4?v=1.1 , then path = /DIR1/dir2/vodfile.mp4 (Note that the querystring part is not included)

signature algorithm

  • Signature original string S = key + url_encode(path) + T Slash/no encoding.
  • autograph SIGN = md5(S).to_lower(),to_lower Refers to converting the string to lowercase;

Note: The url_encode algorithm mentioned in this article.

Signature parameter transmission mode

As a URL query parameter.

For example, the original URL is: //xxx.yyy.com/DIR1/dir2/vodfile.mp4?v=1.1

The final access URL is: //xxx.yyy.com/DIR1/dir2/vodfile.mp4?v=1.1&sign= <SIGN>&t=<T>

  • The signature parameters sign and t, where sign precedes and t follows;
  • <SIGN> <T> Replace with the corresponding value. The actual url does not contain<>;

Access url

To access the path part of the url, url_encode is also required, and its algorithm is the same as that used when signing. Slash/No encoding.

The access url is:

 scheme + "://" + host + url_encode ( path )+ query_part

as

 http : //xxx.yyy.com/DIR1/dir2/vodfile.mp4? v=1.1&sign=19eb212771e87cc3d478b9f32d6c7bf9&t=55bb9b80
http : //xxx.yyy.com/DIR1/%E4%B8%AD%E6%96%87/vodfile.mp4? v=1.2&sign=6356bca0d2aecf7211003e468861f5ea&t=55bb9b80

Note:

  1. The url_encode algorithm mentioned in this article is slash/no encoding.
  2. The path part of the access url is recommended to be encoded as url_encode, as shown in the following example.
Example
Example 1:

URL //xxx.yyy.com/DIR1/dir2/vodfile.mp4?v=1.1 , Assumption key = 12345678 The expiration time is 2016-08-01 00:00:00, that is, 1438358400, that is T = 55bb9b80 S = 12345678/DIR1/dir2/vodfile.mp455bb9b80 SIGN = 19eb212771e87cc3d478b9f32d6c7bf9 , the access url is:

 http : //xxx.yyy.com/DIR1/dir2/vodfile.mp4? v=1.1&sign=19eb212771e87cc3d478b9f32d6c7bf9&t=55bb9b80

Then fill the url address in the check url in the above figure for verification.

Example 2:

URL //xxx.yyy.com/DIR1/ Chinese/vodfile.mp4? v=1.2 , Assumption key = 12345678 T = 55bb9b80 S = 12345678/DIR1/%E4%B8%AD%E6%96%87/vodfile.mp455bb9b80 SIGN = 6356bca0d2aecf7211003e468861f5ea , the access url is:

 http : //xxx.yyy.com/DIR1/%E4%B8%AD%E6%96%87/vodfile.mp4? v=1.2&sign=6356bca0d2aecf7211003e468861f5ea&t=55bb9b80

Then fill the url address in the check url in the above figure for verification.

Server verification

The server gets the original URL, directly parses the host, path, sign, t, and then signs.

Algorithm: S = key + path + t,SIGN = md5(S).to_lower()

Note that there is no url_encode operation here.

The original url refers to the content that is not url_decoded.

Take nginx as an example:

The actual request url sent by the browser: //example.com/foobar/hello%20world

Nginx variable $uri: //example.com/foobar/hello world

Nginx variable $request_uri: //example.com/foobar/hello%20world

The original url content is consistent with the $request_uri content.

It is required to use $request_uri when verifying the signature. This value is the original value. The content is correct and encoded by the url, so the path does not need to be encoded.

The server cannot use $uri to obtain parameters, and then call url_encode to obtain the path to be signed. The path url_encode is followed by the url_decode. The content obtained may be different from the original path.

 http : //example.com/foobar/hello+world
http : //example.com/foobar/hello%2Bworld
http : //example.com/foobar/hello%2bworld

The above three urls are legal links to the same resource. The same key and T will have three different values after signing.% 2b url_decode and url_encode may get% 2B, resulting in inconsistent signatures.

Does this help solve your problem? resolved Unresolved

Submitted successfully! Thank you very much for your feedback, and we will continue to strive to do better! We are sorry that we were unable to resolve your question. We have received your feedback and will give feedback in time!