操作說明登錄，進入控制臺->CDN->域名管理->配置->訪問控制 時間戳防盜鏈修改配置 時間戳防盜鏈：默認為關(guān)閉，開啟時，會同時生成兩組可用的key，用戶需先按照文檔說明在代碼中將Key配置進您的URL，再進行格式檢查，然后確認開啟；還可以自定義輸入KEY，支持輸入備用KEY且不能與主KEY相同；同時需要輸入檢查URL，以保證鑒權(quán)服務正?？捎?，以免影響服務。 算法說明基于時間戳的防盜鏈是通過對時間有關(guān)的字符串進行簽名，將時間、簽名通過一定的方式傳遞給 CDN 服務器作為判定依據(jù)，CDN 邊緣節(jié)點根據(jù)約定的算法判斷來訪URL是否有訪問權(quán)限。 通過，執(zhí)行下一步；不通過，響應 HTTP status code 403。 若同時配置了 Referer、UA防盜鏈、時間戳防盜鏈，有一項不滿足條件，即為不通過，響應 403 。 簽名參數(shù)- 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 指將字符串轉(zhuǎn)換為小寫；
注：本文所提到的 url_encode 算法。 簽名參數(shù)傳遞方式作為URL查詢參數(shù)。 例如原始訪問的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> - 簽名參數(shù) 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
注： - 本文所提到的 url_encode 算法，斜線 / 不編碼。
- 訪問 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 = 55bb9b80 ， S = 12345678/DIR1/dir2/vodfile.mp455bb9b80 ，SIGN = 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 = 12345678 ；T = 55bb9b80 ， S = 12345678/DIR1/%E4%B8%AD%E6%96%87/vodfile.mp455bb9b80 ，SIGN = 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 指未經(jīng) url_decoded 的內(nèi)容。 以 nginx 為例說明： 瀏覽器發(fā)出實際請求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 內(nèi)容和 $request_uri 內(nèi)容一致。 要求驗證簽名時使用 $request_uri ，此值為原始值，內(nèi)容是正確的經(jīng)過 url encode 的內(nèi)容，所以 path 不用編碼。 服務端不能使用 $uri 獲取各參數(shù)，然后再調(diào)用 url_encode 來獲取待簽名的 path。path url_encode 后再 url_decode，獲得的內(nèi)容與原 path 可能不一樣。 http://example.com/foobar/hello+world
http://example.com/foobar/hello%2Bworld
http://example.com/foobar/hello%2bworld
以上三個url都是合法的訪問同一資源的鏈接。相同 key 、T，執(zhí)行簽名后會有三個不同的值。 %2b url_decode 再 url_encode 可能得到 %2B，導致簽名不一致。 |
