18720358503 在线客服 人才招聘 返回顶部
企业动态 技术分享 行业动态

7牛云储存应用中1些普遍难题的处理工作经验

2021-02-21分享 "> 对不起,没有下一图集了!">

599不正确解决
假如在与7牛的互动中出現http情况码为599的不正确,1句话,不必迟疑,立即联络7牛技术性适用。7牛的文本文档也在许多地区提到这个不正确,全是具体指导大伙儿去联络技术性适用的。笔者是在分层提交后的mkfile启用时出現的,联络技术性适用后,说是调剂了1下,让我重试。后来就行了…

分层提交没法从回调函数中得到文档的初始名
简易提交选用的是multipart/form-data方法提交,7牛服务端可以从恳求中得到文档的初始名,并适用应用魔法自变量$(fname)回调函数业务流程服务器。但是当应用分块提交的情况下状况有一定的不一样。分块提交必须在最终启用mkfile,来将分块拼接起来。可是,mkfile插口适用一般的恳求,并沒有附带文档名,因此7牛也就没法得到文档名,此时从$(fname)中是取不到文档名的。这个难题我也向7牛技术性适用递交了难题,获得的結果是应用自定自变量mkfile适用将自定自变量放在url中,回调函数的情况下自定自变量能够传送给业务流程服务器。

慎用照片预解决
7牛云适用许多对文档的预解决,在其中最常见的应当便是照片预解决了,能够对照片的尺寸做转换等。7牛强烈推荐应用GET的方法立即特定照片解决結果的url,像这样:

http://qiniuphotos.qiniudn.com/gogopher.jpg?imageView2/1/w/200/h/200
解决后的照片会全自动缓存文件,客户无需关注,要是每次浏览都用这个url就可以了。但是,笔者在刚开始的情况下,以便维持与别的文档方式统1的解决方式,对照片应用了预解决(由于视頻甚么的只能预解决),即在token中特定了预解决。此时难题出現了,从后台管理的系统日志看到,照片的预解决通告回调函数居然比一切正常的提交取得成功回调函数还要快!这就致使预解决結果来临以前,我的业务流程服务器的数据信息库中都还没这个照片,没法储存预解决結果了。因此强烈推荐還是应用url立即解决,对照片要慎用预解决

视頻文档没法快进播发
一般客户在收看视頻的情况下都会依据自身的爱好,迅速将视頻精准定位到特定的時间播发。完成这个作用,必须视頻自身相关键帧信息内容、服务端必须适用重要帧播发恳求。

可是笔者发现,在应用7牛云转换后的视頻,这样做是失效的。因而资询技术性适用,获得的回答是:转换的文档是具备重要帧的,但7牛应用CDN加快,因此重要帧恳求必须CDN的适用,假如要想用这个作用的话,必须独立联络市场销售或技术性适用在CDN上配备,并且時间较为长。笔者联络了市场销售和技术性适用,说是帮我配备,但到如今都还没搞定,由于近期这个也并不是非常关键,因此也沒有跟下去。

Callback校检
这是可选的1个流程。因为7牛云会在提交进行以后回调函数业务流程服务器,因此基础理论上说业务流程服务器必须校检这个回调函数的有效性。基本原理在7牛的文本文档中有,必须用到HMAC-SHA1签字涵数。可是7牛的sdk中沒有出示立即的方法来做校检,在研读文本文档、数次不成功和查询sdk源代码后,笔者终究校检取得成功了。重要的矛盾在于,文本文档中的这句话:

获得密文:data = Request.URL.Path +”\n” +Request.Body
这里的Request.URL.Path是不是包括Querystring?回答是包括的!下面是笔者C#服务端校检编码,应用的是ASP.NET Web Api:

C# Code拷贝內容到剪贴板
  1. byte[] key = System.Text.Encoding.UTF8.GetBytes(Qiniu.Conf.Config.SECRET_KEY);   
  2. using (HMACSHA1 hmac = new HMACSHA1(key))   
  3. {   
  4.     var t = filterContext.Request.Content.ReadAsStringAsync();   
  5.     t.Wait();   
  6.     string rawbody = t.Result;   
  7.     log.DebugFormat("request's rawbody : {0}", rawbody);   
  8.     string text = filterContext.Request.RequestUri.PathAndQuery + "\n" + rawbody;   
  9.     log.DebugFormat("PathAndQuery + \\n + rawbody : {0}", text);   
  10.     byte[] digest = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(text));   
  11.     string computed = Qiniu.Util.Base64URLSafe.Encode(digest);   
  12.     log.DebugFormat("Computed hash after base64 : {0}", computed);   
  13.   
  14.     IEnumerable<string> auths;   
  15.     if (filterContext.Request.Headers.TryGetValues("Authorization"out auths) && auths.Count() == 1)   
  16.     {   
  17.         string auth = auths.First();   
  18.         log.DebugFormat("Authorization in header : {0}", auth);   
  19.         if (auth.StartsWith("QBox "))   
  20.         {   
  21.             var arr = auth.Substring(5).Split(':');  
  22.             if (arr.Length == 2)  
  23.             {  
  24.                 if (arr[1] != computed)  
  25.                 {  
  26.                     log.ErrorFormat("Authorization failed. Since auth from header {0} not equals computed {1}", arr[1], computed);  
  27.                 }  
  28.                 else  
  29.                 {  
  30.                     log.Debug("Authorization success.");  
  31.                     //only pass can be return  
  32.                     return;  
  33.                 }  
  34.             }  
  35.             else  
  36.             {  
  37.                 log.Error("Callback Authorization's format is invalid, can not find two part after split by ':'.");   
  38.             }   
  39.         }   
  40.         else  
  41.         {   
  42.             log.Error("Callback Authorization's format is invalid, missing leading 'QBox '.");   
  43.         }   
  44.     }   
  45.     else  
  46.     {   
  47.         log.Error("The request from qiniu callback is missing 'Authorization'");   
  48.     }   
  49.   
  50.     filterContext.Response = filterContext.Request.CreateResponse(System.Net.HttpStatusCode.Forbidden);   
  51.   
  52. }  

以下几个留意点:

密文理应是恳求的path+querystring一部分和rawbody
针对.NET而言,密文和key都必须用UTF⑻编号转换成字节才可以开展签字。而php中的hash_hmac涵数彻底无需这么繁杂…
签字的結果再用base64的url安全性的方法编号,再与恳求的http头顶部的Authorization较为
提议官方在文本文档中添加1些相对性最底层1些的程序编写語言的完成,php太高档了…

js-sdk完成略显不光滑
在应用全过程中,我发现官方的js-sdk有几个我感觉不太好的地区:

不可以为每一个文档获得UpToken

试想,在文档提交全过程中有获得UpToken是务必的,并且UpToken又必须包括预解决命令,不一样的文档明显必须不一样的UpToken,而在js-sdk的完成中,只在原始化这个提交组件目标的情况下恳求1次提交凭据,后边全部的提交都必须应用这个预先获得的UpToken:

JavaScript Code拷贝內容到剪贴板
  1. uploader.bind('Init'function(up, params) {      
  2.     getUpToken();      
  3. });     
因而我改动了这一部分,在BeforeUpload恶性事件中恳求UpToken。提议官方考虑到变更这个地区

只能完成分块提交,没法断点续传

js-sdk的完成在分块提交的完成上,是很简易的,不但沒有应用分块,而是分层(1块4m,启用mkblk),并且沒有完成长久化ctx,或相近的回调函数或插口。4m分层这个难题还能够不追责,沒有完成长久化ctx就说但是去了,不长久化如何完成断点续传撒?!即使不完成,也应当得出回调函数的通道,让启用者来完成长久化,而我确实没法寻找这个’空子’可钻,只能立即在源代码上修改了。

沒有复用时兴类库的物品

这个实际上算不上难题,由于做为1个不依靠jquery的sdk,自然不可以应用jquery现成的物品,例如ajax。不依靠jquery即使了,依靠plupload是几个意思嘛,还依靠全局性目标…因而最终,我果断自身将sdk改为了Backbone的类,将不必的物品通通去掉,应用jquery和underscore简化编码了…

"> 对不起,没有下一图集了!">
在线咨询