君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
支持OO查询物理优化的二维字典签名方法
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口发送到OOS的请求如何签名验证
发送到OOS的请求如何签名验证
实际上OOS并不推荐开发者自己通过算法去构造签名，而是建议使用SDK来进行开发，但为了满足一些用户的特殊需求，我们还是对签名这块特别介绍一下。1.1 用户签名验证（Authentication）OOS通过使用Access Key ID/Secret Access Key对称加密的方法来验证某个请求的发送者身份。Access Key ID和Secret Access Key在注册后自动随机生成,并会发送到用户的注册邮箱中。当用户想以个人身份向OOS发送请求时，需要首先将发送的请求按照OOS指定的格式生成签名字符串；然后使用Secret Access Key对签名字符串进行加密产生验证码。OOS收到请求以后，会通过Access Key ID找到对应的SecretAccess Key，以同样的方法提取签名字符串和验证码，如果计算出来的验证码和提供的一样，即认为该请求时有效的；否则，OOS将拒绝处理这次请求，并返回错误码。1.1.1 Head中包含签名用户可以在HTTP请求中增加Authorization（授权）的Head来包含签名信息，表明这个消息已被授权。如果用户的请求中没有Authentication字段，则认为是匿名访问。验证码计算方法如下：&Authorization:&&&& AWS& +&&&& AccessId + &:& + Signature Signature&&&& =Base64( HMAC-SHA1( YourSecretAccessKey, UTF-8-Encoding-Of( StringToSign )&&&& ) ) ;StringToSign&&&& = HTTP-VERB + &\n& +Content-MD5&&&& + &\n& +Content-Type&&&& + &\n& +Date + &\n& +CanonicalizedAmzHeaders&&&& +CanonicalizedR说明：1)& Content-Md5表示请求内容数据的MD5值；2)& CONTENT-TYPE表示请求内容的类型；3)& DATE表示此次操作的时间，且必须为HTTP1.1中支持的GMT格式；4)& CanonicalizedAmzHeaders表示http中的object user meta组合；5)& CanonicalizedResource表示用户想要访问的OOS资源&& 构建CanonicalizedAMZHeaders的方法&& 所有以“x-amz-”为前缀的HTTP Header被称为CanonicalizedAMZHeaders。它的构建方法如下：1) 将所有以“x-amz-”为前缀的HTTP请求头的名字转换成小写字母。如’X-AMZ-Meta-Name: fred’转换成’x-amz-meta-name: fred；2) 将上一步得到的所有HTTP请求头按照字典序进行升序排列；3) 如果有相同名字的请求头，则根据标准RFC 章进行合并（两个值之间只用逗号分隔）。如有两个名为’x-amz-meta-name’的请求头，对应的值分& 别为’ fred’ 和’ barney’，则合并后为：’x-amz-meta-name: fred,barney’；4) 删除请求头和内容之间分隔符两端出现的任何空格。如’x-amz-meta-name:& fred, barney’转换成：’x-amz-meta-name: fred,barney’；5) 将所有的头和内容用’\n’分隔符分隔拼成最后的CanonicalizedAMZHeader。构建CanonicalizedResource的方法用户发送请求中想访问的AMZ目标资源被称为CanonicalizedResource。它的构建方法如下：&&&&& &1) 将CanonicalizedResource置成空字符串（“”）；2) 放入要访问的AMZ资源：“ /BucketName/ObjectName”（无ObjectName则不填）；3) 如果请求的资源包括子资源(sub-resource)，那么将所有的子资源按照字典序，从小到大排列并以’&’为分隔符生成子资源字符串。在CanonicalizedResource字符串尾添加“？”和子资源字符串。此时的CanonicalizedResource例子如：/BucketName/ObjectName?acl&&&& &uploadId=UploadId；4) 如果用户请求在查询字符串(query string)中指定了要重写(override)返回请求的header，那么将这些查询字符串及其请求值按照字典序，从小到大排列，以’&’为分隔符，按参数的字典序添加到CanonicalizedResource中。此时的CanonicalizedResource例子：/BucketName/ObjectName?acl&response-content-type=ContentType & uploadId =UploadId使用Base64编码HMAC请求签名必须使用Base64编码。Base64编码将签名转换为简单的能附加到请求中的ASCII编码字符串。加号和斜杠这两个字符不能直接在URL中使用，必须经过编码。比如，如果授权编码包括加号，在URL中把它编码成为%2B。对更多Based64编码信息，查看Amazon S3代码示例。时间戳说明在签名时必须使用时间戳，可以用HTTP的Date请求头，也可以用x-amz-date请求头。时间戳中的时间和OOS的系统时间不能相差15分钟以上，否则，OOS会返回错误码RequestTimeTooSkewed。有些HTTP客户端不能设置Date请求头，如果你在签名时设置Date请求头有困难，那么你可以使用x-amz-date请求头来传送时间戳。x-amz-date请求头需要符合RFC 2616 的格式 (http://www.ietf.org/rfc/rfc2616.txt)。当请求中包含x-amz-date头时，OOS在计算签名时会忽略Date头。所以如果请求中有x-amz-date头，在客户端计算签名时，Date头的值应设置为空串。1.1.2 URL中包含签名除了授权头以外，用户可以通过URL中加入签名信息的方式，将该URL转给第三方实现授权访问。这对于使用第三方浏览器获取对象存储数据的用户非常有用，不需要代理请求。这种方式通过构造并加密一个终端用户浏览器可以检索到的预签名的请求来实现，同时设置过期时间来标明预签名的有效期。URL中包含签名的示例如下：/quotes/nelson?AWSAccessKeyId=44CF2F707&Expires=&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D& &URL中包含签名的示例如下：在URL中实现签名，必须至少包含Signature，Expires，AWSAccessKeyId三个参数。请求参数&Expires这个参数的值是一个UNIX时间（自UTC时间号开始的秒数，详见wiki），用于标识该URL的超时时间。如果OOS接收到这个URL请求的时候晚于签名中包含的Expires参数时，则返回请求超时的错误码。例如：当前时间是，开发者希望创建一个60秒后自动失效的URL，则可以设置Expires时间为。所有的OOS支持的请求和各种Head参数，在URL中进行签名的方法和上节介绍的签名算法基本一样。主要区别如下：1) 通过URL包含签名时，之前的Date参数换成Expires参数。2) 不支持同时在URL和Head中包含签名。3) 如果传入的Signature，Expires，AWSAccessKeyId出现不止一次，以第一次为准。4) 请求先验证请求时间是否晚于Expires时间，然后再验证签名。
服务与支持
售前支持 7x24小时
售后支持 7x24小时
7*12小时 9:00-21:00
咨询热线 400-810-9889
合作加盟 010-
可信云认证
400-810-9889
400-810-9889转3扫一扫，访问微社区
查看: 1046|回复: 16
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
本帖最后由 vision_yu 于
10:29 编辑
另外，我们获取到的签名每一个都一样，到底用哪个，还是哪一个都可以。
(0 Bytes, 下载次数: 35)
18:48 上传
点击文件名下载附件
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
那个 FILE_SIGN、PHOTO_SIGN、VIDEO_SIGN分别对应的是哪个
云币1149 威望738 最后登录积分738注册时间帖子
云币1149 威望738
这个三个对应的是 我们的三个不同的业务。 分别是 cos 万象优图 和微视频。&&他们公用一套key。 签名要写在 传输数据的http头部中。
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
vision_yu 发表于
这个三个对应的是 我们的三个不同的业务。 分别是 cos 万象优图 和微视频。&&他们公用一套key。 签名要写在 ...
这三个key是固定的吗？在哪得到的？
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
vision_yu 发表于
这个三个对应的是 我们的三个不同的业务。 分别是 cos 万象优图 和微视频。&&他们公用一套key。 签名要写在 ...
我看了你们那个sign的生成方式，不同的时候要分单次的和多次的，而你们的demo里面却让我们把sign给写死了。这又是为什么呢？
云币1149 威望738 最后登录积分738注册时间帖子
云币1149 威望738
您官网控制台可以获得， 以微视频为例&&可以点进去 看到有个 秘钥配置&&进去就可以看到了。
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
vision_yu 发表于
您官网控制台可以获得， 以微视频为例&&可以点进去 看到有个 秘钥配置&&进去就可以看到了。&&...
就是那个secret key?
云币1149 威望738 最后登录积分738注册时间帖子
云币1149 威望738
恩 ，key&&和 id 都是需要的
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
vision_yu 发表于
您官网控制台可以获得， 以微视频为例&&可以点进去 看到有个 秘钥配置&&进去就可以看到了。&&...
不行，还是提示更新签名失败。
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
private static class DefaultCfg {
& && &&&private static final String APPID = &&;& && && && & //&299201&
& && &&&private static final String FILE_BUCKET =&&;& && &&&//&bb&;
& && &&&private static final String PHOTO_BUCKET =&&;& && & //&open&;
& && &&&private static final String VIDEO_BUCKET =&&;& && &//&vincentsu&;
& && &&&// SerectID, 正式业务请勿将该值保存在客户端，否则泄露可能导致安全隐患
& && &&&private static final String DEV_SECRETID =&&;& && && && &&&//&AKIDiMQx9mmdnVmVjaEj94VYyvSTw1fgZS8L&;
& && &&&private static final String NORMAL_SECRETID =&&;& && && &&&//&AKIDAsqjH35AoJNmzjB3lfVUIHLDMB18cXG8&;
& & & & /*******************以下参数需要根据业务修改**************************/
& & & & /*******修改之后需要自己实现签名逻辑，详见{@link UpdateSignTask}*******/
& & public static String APPID = DefaultCfg.APPID;
& & public static String FILE_SIGN = &&;
& & // 业务请自行修改成自己配置的bucket
& & public static String FILE_BUCKET = DefaultCfg.FILE_BUCKET;
& & // SerectID, 正式业务请勿将该值保存在客户端，否则泄露可能导致安全隐患
& & & & public static String FILE_SECRETID = DefaultCfg.NORMAL_SECRETID;
& & public static String PHOTO_SIGN = &&;
& & // 业务请自行修改成自己配置的bucket
& & public static String PHOTO_BUCKET = DefaultCfg.PHOTO_BUCKET;
& & // SerectID, 正式业务请勿将该值保存在客户端，否则泄露可能导致安全隐患
& & public static String PHOTO_SECRETID = DefaultCfg.NORMAL_SECRETID;
& & public static String VIDEO_SIGN = &&;
& & // 业务请自行修改成自己配置的bucket
& & public static String VIDEO_BUCKET = DefaultCfg.VIDEO_BUCKET;
& & // SerectID, 正式业务请勿将该值保存在客户端，否则泄露可能导致安全隐患
& & public static String VIDEO_SECRETID = DefaultCfg.NORMAL_SECRETID;
& & & & /*****************************************************************/
你们这段代码里的sign是指点secret_key?!!
云币1149 威望738 最后登录积分738注册时间帖子
云币1149 威望738
这个 sign 指的是 根据 key合成的签名 具体签名的合成方法 我们的wiki上专门有一个页面讲述 。
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
vision_yu 发表于
这个 sign 指的是 根据 key合成的签名 具体签名的合成方法 我们的wiki上专门有一个页面讲述 。 ...
/wiki/%E7%AD%BE%E5%90%8D%E5%8F%82%E6%95%B0sign%E7%94%9F%E6%88%90%E8%AF%B4%E6%98%8E#Step_2._.E7.94.9F.E6.88.90sign.E5.80.BC
这里面的step 2?
云币1149 威望738 最后登录积分738注册时间帖子
云币1149 威望738
就严格按照这个页面来&&这几部都需要做的
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
vision_yu 发表于
就严格按照这个页面来&&这几部都需要做的
我不明白，你们这里是要通过加密请求来生成这个sign值的，但是你们在demo上却把这几个sign值写死了。你要让它自动生成就是说所有代码都要作一个大改。
你们这个demo你们有用过么？
云币1149 威望738 最后登录积分738注册时间帖子
云币1149 威望738
我们的移动端&&安卓ios等 签名理论上是不保存在本地的， 需要用户每次去服务端 拿签名 。这个是比较安全的做法。 至于demo那个 签名的例子 不要理他。 或者暂时替换成 您自己的内容。 将来单独再去获取。
这个demo 我们以后也会逐步改进的。
云币32 威望25 最后登录积分78注册时间帖子
小白［LV1］, 积分 78, 距离下一级还需 222 积分
云币32 威望25
vision_yu 发表于
我们的移动端&&安卓ios等 签名理论上是不保存在本地的， 需要用户每次去服务端 拿签名 。这个是比较安全的 ...
所以说你们是没有使用过那个demo对吧，使用服务端SDK生成的sign值如果直接复制过去就直接提示签名过时了，无论是多次签名还是单次签名。所以说根本不存在单独去获取了再手工替换那个内容的可行性。现在连测试都测试不了。所以换言之你现在就是告诉我那个demo是废的不要去看要重新写一个是么？你们那个服务端的代码也能直接实现，而且代码简洁明了多了。现在直接用服务端的demo,自己生成sign值也可以实现，干嘛非要分开来获取。
云币1149 威望738 最后登录积分738注册时间帖子
云币1149 威望738
我们的demo都是测试过的， 分开获取是为了安全考虑
Powered by