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: - The url_encode algorithm mentioned in this article is slash/no encoding.
- 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. |