使用二級域名,如果正式上線的話就需要走備案流程,審核通過後才能使用
2、關於七牛雲存儲自定義URL的問題
近段時間將使用七牛雲存儲來存放用戶上傳的數據,客戶端通過七牛的js-sdk與七牛交互,服務端C#實現了七牛相關的介面。在這過程中多多少少遇到點問題,在這里總結一下。原文: 使用七牛雲存儲的一些經驗總結
599錯誤處理
如果在與七牛的交互中出現http狀態碼為599的錯誤,一句話,不要猶豫,直接聯系七牛技術支持 。七牛的文檔也在很多地方提到這個錯誤,都是指導大家去聯系技術支持的。筆者是在分塊上傳後的 mkfile 調用時出現的,聯系技術支持後,說是調整了一下,讓我重試。後來就好了...
分塊上傳無法從回調中獲得文件的原始名
簡單上傳採用的是multipart/form-data方式上傳,七牛服務端能夠從請求中獲得文件的原始名,並支持使用魔法變數 $(fname) 回調業務伺服器。不過當使用分片上傳的時候情況有所不同。分片上傳需要在最後調用 mkfile ,來將分片拼接起來。但是, mkfile 介面支持普通的請求,並沒有附帶文件名,所以七牛也就無法獲得文件名,此時從 $(fname) 中是取不到文件名的。這個問題我也向七牛技術支持提交了問題,得到的結果是使用自定義變數 mkfile 支持將自定義變數放在url中,回調的時候自定義變數可以傳遞給業務伺服器。
慎用圖片預處理
七牛雲支持很多對文件的預處理,其中最常用的應該就是圖片預處理了,可以對圖片的大小做變換等。七牛推薦使用GET的方式直接指定圖片處理結果的url,像這樣:
http://qiniuphotos.qiniudn.com/gogopher.jpg?imageView2/1/w/200/h/200
處理後的圖片會自動緩存,用戶不用關心,只要每次訪問都用這個url就行了。然而,筆者在開始的時候,為了保持與其他文件形式統一的處理方法,對圖片使用了預處理(因為視頻什麼的只能預處理),即在token中指定了預處理。此時問題出現了,從後台的日誌看到,圖片的預處理通知回調竟然比正常的上傳成功回調還要快!這就導致預處理結果到來之前,我的業務伺服器的資料庫中還沒有這個圖片,無法保存預處理結果了。所以 推薦還是使用url直接處理,對圖片要慎用預處理
視頻文件無法快進播放
通常用戶在觀看視頻的時候都會根據自己的喜好,快速將視頻定位到指定的時間播放。實現這個功能,需要視頻本身有關鍵幀信息、服務端需要支持關鍵幀播放請求,在 這篇文章 中有詳細討論。
但是筆者發現,在使用七牛雲轉化後的視頻,這樣做是無效的。於是咨詢技術支持,得到的答案是:轉化的文件是具有關鍵幀的,但七牛使用CDN加速,所以關鍵幀請求需要CDN的支持,如果想要用這個功能的話,需要單獨聯系銷售或技術支持在CDN上配置,而且時間比較長。筆者聯系了銷售和技術支持,說是幫我配置,但到現在還沒有搞定,因為最近這個也不是特別重要,所以也沒有跟下去。
Callback校驗
這是可選的一個步驟。由於七牛雲會在上傳完成之後回調業務伺服器,所以理論上說業務伺服器需要校驗這個回調的合理性。原理在七牛的 文檔 中有,需要用到 HMAC-SHA1 簽名函數。但是七牛的sdk中沒有提供直接的方式來做校驗,在研讀文檔、多次失敗和查看sdk源碼後,筆者終於校驗成功了。關鍵的分歧在於,文檔中的這句話:
獲取明文:data = Request.URL.Path +」\n」 +Request.Body
這里的 Request.URL.Path 是否包含Querystring?答案是包含的!下面是筆者C#服務端的校驗代碼,使用的是ASP.NET Web Api:
```C#
byte[] key = System.Text.Encoding.UTF8.GetBytes(Qiniu.Conf.Config.SECRET_KEY);
using (HMACSHA1 hmac = new HMACSHA1(key))
{
var t = filterContext.Request.Content.ReadAsStringAsync();
t.Wait();
string rawbody = t.Result;
log.DebugFormat("request's rawbody : {0}", rawbody);
string text = filterContext.Request.RequestUri.PathAndQuery + "\n" + rawbody;
log.DebugFormat("PathAndQuery + \n + rawbody : {0}", text);
byte[] digest = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(text));
string computed = Qiniu.Util.Base64URLSafe.Encode(digest);
log.DebugFormat("Computed hash after base64 : {0}", computed);
IEnumerable<string> auths;
if (filterContext.Request.Headers.TryGetValues("Authorization", out auths) && auths.Count() == 1)
{
string auth = auths.First();
log.DebugFormat("Authorization in header : {0}", auth);
if (auth.StartsWith("QBox "))
{
var arr = auth.Substring(5).Split(':');
if (arr.Length == 2)
{
if (arr[1] != computed)
{
log.ErrorFormat("Authorization failed. Since auth from header {0} not equals computed {1}", arr[1], computed);
}
else
{
log.Debug("Authorization success.");
//only pass can be return
return;
}
}
else
{
log.Error("Callback Authorization's format is invalid, can not find two part after split by ':'.");
}
}
else
{
log.Error("Callback Authorization's format is invalid, missing leading 'QBox '.");
}
}
else
{
log.Error("The request from qiniu callback is missing 'Authorization'");
}
filterContext.Response = filterContext.Request.CreateResponse(System.Net.HttpStatusCode.Forbidden);
}
如下幾個注意點:
- 明文應當是請求的path+querystring部分和rawbody
- 對於.NET而言,明文和key都需要用UTF-8編碼變換成位元組才能進行簽名。而php中的hash_hmac函數完全不用這么復雜...
- 簽名的結果再用base64的url安全的方式編碼,再與請求的http頭部的Authorization比較
建議官方在文檔中加入一些相對底層一些的編程語言的實現,php太高端了...
## js-sdk實現略顯粗糙 ##
在使用過程中,我發現[官方的js-sdk](https://github.com/qiniupd/qiniu-js-sdk/)有幾個我覺得不好的地方:
**不能為每個文件獲取UpToken**
試想,在文件上傳過程中有獲取UpToken是必須的,而且UpToken又需要包含預處理指令,不同的文件顯然需要不同的UpToken,而在js-sdk的實現中,只在初始化這個上傳組件對象的時候請求一次上傳憑證,後面所有的上傳都需要使用這個預先得到的UpToken:
```javascript
uploader.bind('Init', function(up, params) {
getUpToken();
});
於是我修改了這部分,在 BeforeUpload 事件中請求UpToken。建議官方考慮更改這個地方
只能實現分片上傳,無法斷點續傳
js-sdk的實現在分片上傳的實現上,是很簡單的,不僅沒有使用分片,而是分塊(一塊4m,調用mkblk),而且沒有實現持久化ctx,或者類似的回調或介面。4m分塊這個問題還可以不追究,沒有實現持久化ctx就說不過去了,不持久化怎麼實現斷點續傳撒?!就算不實現,也應該給出回調的入口,讓調用者來實現持久化,而我實在無法找到這個'空子'可鑽,只能直接在源碼上改動了。
沒有復用流行類庫的東西
這個其實算不上問題,因為作為一個不依賴jquery的sdk,當然不能使用jquery現成的東西,比如ajax。不依賴jquery就算了,依賴plupload是幾個意思嘛,還依賴全局對象...於是最後,我乾脆自己將sdk改成了Backbone的類,將不要的東西統統去掉,使用jquery和underscore簡化代碼了...
3、是不是CDN都需要域名是備案過的?
國內的cdn服務商原則上接入域名需要備案,不備案允許接入的運營商不符合規定
國外的cdn服務商沒有這個要求
4、為什麼域名備案了雲主機還要備案?有沒有域名備案了雲主機不再用備案的IDC?
現在統一為網站備案,包括域名和主機。用哪兒的國內主機就要在哪兒備案。不過,你可以用國際版,這個不要求備案。
建議你用模板建站系統做網站,不懂技術也能自己動手製作網站。有專業人員維護後台系統,讓用戶無後顧之憂。
有幾百套網站模板可以選擇,操作方便,管理和維護很方便,有學習視頻,一般看半天就會做了。
速成網站-國際版(5G 阿里雲香港主機,不限流量,不需要備案,會打字就可以做網站,可先試用)。年費是160元。
可以找咱們,現在在線。
5、雲伺服器使用一定要域名和備案嗎
國內的空間是必須備案的。國外或香港的空間不用備案,也不能備案。
6、是域名必須要備案才能用么?
您好,並不是這樣的,域名備案是我國為了防止網路詐騙,有效的監管網路的一種手段,只要在我國使用我國的伺服器的做網站,才會牽涉到域名備案。
如果您是使用了國外的伺服器或者大陸以外的伺服器,要按照當地對於域名的規范法則來進行相關的工作。
7、七牛雲綁定自定義域名時要填備案號,但是域名怎麼備案啊
你的空間在那裡購買的,就在那裡備案。
比如:
你的域名在阿里雲,空間也在阿里雲,那就在阿里雲備案;
如果域名在阿里雲,空間在新網,那就在新網備案;
阿里雲的備案地址是下面這個:
8、我買了一個雲伺服器,需要備案,是不是備案域名啊是
所謂的雲伺服器備案,特指國內雲伺服器。大陸以外地域的伺服器不用。
備案是備案伺服器,包括 IP地址。
備案過程一般有雲伺服器商提供輔助,會給你操作步驟,你按照步驟一點點去操作就行了, 准備好相關備案資料就行。
以國內的阿里雲為例子,官方文檔對網站備案有詳細描述。感興趣可以去看看。
因為備案是一個系統的過程,不是一句兩句話能講清楚的。而官方文檔中對此解釋的很詳細,即使是新手用起來也很友好。
9、以後網站沒有備案就不能用CDN服務了嗎?
7 月 6 日,工業和信息化部信息通信管理局下發《關於進一步加強未備案網站管理工作的通知》,通知要求,各通信管理局要立即組織屬地接入服務企業(包含跨地區接入服務企業)開展自查自糾工作,要求其立即停止為未備案網站提供互聯網接入服務(包括加速類服務),並強調加大對未備案接入行為的處罰力度,對於未備案接入網站的行為「零容忍」,發現一起,處罰一起。
此次通知是基於工業和信息化部信息通信管理局互聯網基礎管理專項行動,繼續強化網站備案、IP 地址、域名等互聯網基礎管理,積極打擊不法分子通過自動化搶注備案過期域名,通過 CDN 網路從事非法活動,催生黑產的現狀。
為維護良好的市場環境,七牛雲迅速響應,積極配合通信管理局糾查工作,全面停止對未備案、過期域名的加速服務,並優化 CDN 加速域名備案監管流程,已形成完善的全通道審核及監管機制。
對於依法備案的域名
七牛雲獨家支持 ECC 演算法 DV 單域名證書
免費申請及下載!
申請方式:
登陸七牛雲開發者平台 》》portal.qiniu.com》》選擇 SSL 證書服務》》點擊「購買證書」
10、網站備案,是不是必須申請域名,才可以備案?
網站備案是指網站服務商幫助網站所有人給網站做域名備案。網站所有人需要提供給網站空間服務商備案資料。
基本要求就是要有 域名+伺服器。
給域名備案需要網站服務商協助,只有域名是無法備案的。備案針對網站備案,只注冊域名不用備案,域名做網站就需要備案,網站空間在哪家購買,哪家就負責辦理網站備案。
網站備案需要填寫網站域名,還有網站以及管理人員的信息。備案時必須有網站空間接入商,負責接入網站。
網站域名備案時,需在APP端上傳主體負責人證件、網站負責人證件、主辦單位證件等必須上傳的基本資料,輔助資料需根據用戶的備案場景和管局規則選擇性的上傳。本文為您介紹各種資料的適用場景及上傳要求,您可參見本文查看並准備備案所需的資料及上傳要求,加快備案進程。
辦理時間一般在30個工作日之內可以下來,快一點的10多天就能下來備案號。