82
时间戳防盗链

操作说明

登录,进入控制台->CDN->域名管理->配置->访问控制

时间戳防盗链修改配置

时间戳防盗链:默认为关闭,开启时,会同时生成两组可用的key,用户需先按照文档说明在代码中将Key配置进您的URL,再进行格式检查,然后确认开启;还可以自定义输入KEY,支持输入备用KEY且不能与主KEY相同;同时需要输入检查URL,以保证鉴权服务正常可用,以免影响服务。

算法说明

基于时间戳的防盗链是通过对时间有关的字符串进行签名,将时间、签名通过一定的方式传递给 CDN 服务器作为判定依据,CDN 边缘节点根据约定的算法判断来访URL是否有访问权限。

通过,执行下一步;不通过,响应 HTTP status code 403。

若同时配置了 Referer、UA防盗链、时间戳防盗链,有一项不满足条件,即为不通过,响应 403 。

签名参数

  • T:URL 过期时间。按 unix_time 的 16进制小写形式表示。 如 2015-08-01 00:00:00 –> 1438358400 –> 55bb9b80
  • key:在开启时间戳防盗链时,可以由使用:(控制台->CDN->域名管理->访问控制->时间戳防盗链),使用其中一个即可。也可以自行使用算法生成。
  • path:访问资源的 URL 中的路径部分,例如:访问的URL为 http://xxx.yyy.com/DIR1/dir2/vodfile.mp4?v=1.1,则 path = /DIR1/dir2/vodfile.mp4(注意不含 querystring 部分)

签名算法

  • 签名原始字符串 S = key + url_encode(path) + T 。斜线 / 不编码。
  • 签名 SIGN = md5(S).to_lower(),to_lower 指将字符串转换为小写;

注:本文所提到的 url_encode 算法。

签名参数传递方式

作为URL查询参数。

例如原始访问的URL为: http://xxx.yyy.com/DIR1/dir2/vodfile.mp4?v=1.1

最终形成的访问URL为: http://xxx.yyy.com/DIR1/dir2/vodfile.mp4?v=1.1&sign=<SIGN>&t=<T>

  • 签名参数 sign、 t ,sign 在前,t 在后;
  • <SIGN><T> 替换为对应的值, 实际url中不含<> ;

访问url

访问 url 的 path 部分也需要 url_encode,其算法与签名时使用 url_encode 算法一致。斜线 / 不编码。

访问 url 为:

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

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

注:

  1. 本文所提到的 url_encode 算法,斜线 / 不编码。
  2. 访问 url 的 path 部分推荐按 url_encode 编码,如下例。
示例
例1:

URL http://xxx.yyy.com/DIR1/dir2/vodfile.mp4?v=1.1 ,假设 key = 12345678 ;过期时间为 2015-08-01 00:00:00 ,即 1438358400 ,也就是 T = 55bb9b80S = 12345678/DIR1/dir2/vodfile.mp455bb9b80SIGN = 19eb212771e87cc3d478b9f32d6c7bf9 , 访问 url 为:

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

之后将 url 地址填写在上图中的 检查url 处验证。

例2:

URL http://xxx.yyy.com/DIR1/中文/vodfile.mp4?v=1.2 ,假设 key = 12345678T = 55bb9b80S = 12345678/DIR1/%E4%B8%AD%E6%96%87/vodfile.mp455bb9b80SIGN = 6356bca0d2aecf7211003e468861f5ea ,访问 url 为:

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

之后将 url 地址填写在上图中的 检查url 处验证。

服务端验证

服务端拿到原始的 url ,直接解析出 host, path, sign, t ,再签名。

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

注意此处没有 url_encode 操作。

原始的 url 指未经 url_decoded 的内容。

以 nginx 为例说明:

浏览器发出实际请求url: http://example.com/foobar/hello%20world

nginx变量 $uri: http://example.com/foobar/hello world

nginx变量 $request_uri: http://example.com/foobar/hello%20world

原始的 url 内容和 $request_uri 内容一致。

要求验证签名时使用 $request_uri ,此值为原始值,内容是正确的经过 url encode 的内容,所以 path 不用编码。

服务端不能使用 $uri 获取各参数,然后再调用 url_encode 来获取待签名的 path。path url_encode 后再 url_decode,获得的内容与原 path 可能不一样。

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

以上三个url都是合法的访问同一资源的链接。相同 key 、T,执行签名后会有三个不同的值。 %2b url_decode 再 url_encode 可能得到 %2B,导致签名不一致。

这条帮助是否解决了您的问题? 已解决 未解决

提交成功!非常感谢您的反馈,我们会继续努力做到更好! 很抱歉未能解决您的疑问。我们已收到您的反馈意见,同时会及时作出反馈处理!