原创,转载请注明://www.greatytc.com/p/a6a02309190f
引言
若想直接看签名算法,请直接看本文中
3.实现原理分析
一、开篇说明:
以下思考方向,是以Android端为出发点(IOS同理)
AWS:Amazon Web Services (亚马逊云服务)
AWS s3 API文档:https://aws.amazon.com/cn/documentation/s3/
Minio :(具体的解释自行百度吧)一个基于 golang 语言开发的 AWS S3 存储协议的开源实现,并附带 web ui 界面,可以通过 Minio 搭建私人的兼容 AWS S3 协议的存储服务器。
二、需求分析
项目需求:最近公司需要搭建一个文件服务器,让移动端(Android、ios)用来存储图片等文件。这个文件服务器后台使用minio搭建的。由于minio是基于AWS S3 存储协议,所以我们移动端也需要实现相同的协议来上传。移动端,我们确定了三种可行方案(方案优劣仅是基于对APK打包大小的影响程度来确定的):
- 方案一:基于AWS S3 存储协议自己实现文件上传(最佳方案,最后项目引入文件最小----大约100K,不影响apk大小)
- 方案二:使用AWS SDK 实现文件上传(中间方案,需要引入项目的jar包1.5M文件略大)
- 方案三:使用minio SDK 实现文件上传(最差方案,需要引入6M jar包)
三、代码实现
由于项目需求不同,供大家自行选择,我将这三种方案实现一一说明。
方案三:
demo下载:https://github.com/Nergal1/minio-demo
- 1.Android端引入minio SDK jar包会和原生的发生冲突,会报一些安全错误。
引入时,去除冲突的包,com.fasterxml.jackson.core和com.google.code.findbugs:
dependencies {
compile ('io.minio:minio:3.0.4'){
excludegroup:'com.fasterxml.jackson.core'
excludegroup:'com.google.code.findbugs'
}
}
- 2.上传代码:
/\*上传图片
bucketName:服务端存储文件夹,必须先创建
objectName:服务端存储文件名
inputStream:上传文件流
\*/
minioClient.putObject(bucketName,objectName,inputStream,inputStream.available(),"application/octet-stream");
提醒:别忘了开启网络权限
-
3.简易源码流程图,数字代表行号:
minio上传源码简易流程图
方案二:
demo下载:https://github.com/Nergal1/AWS-S3-demo
- 1.由于AWS SDK源码中是开启Service,然后创建线程池实现异步上传、下载功能。
清单文件要注册service:
<service android:name="com.amazonaws.mobileconnectors.s3.transferutility.TransferService"
android:enabled="true"/>
权限:
android.permission.INTERNET
android.permission.ACCESS_NETWORK_STATE
android.permission.READ_EXTERNAL_STORAGE
android.permission.WRITE_EXTERNAL_STORAGE
Android 6.0+文件读写权限需要代码中实时获取,demo中未作兼容。如有文件问题,请自行添加。
- 2.引入jar包:
aws-android-sdk-core-2.4.2.jar
aws-android-sdk-s3-2.4.2.jar - 3.先配置Constants.java中的ENDPOINT、ACCESSKEY、SecretKey、BUCKET_NAME
上传代码见UploadActivity.java(下载请自行查看DownloadActivity):
TransferUtility transferUtility= Util.getTransferUtility(this);
//上传
TransferObserver observer =transferUtility.upload(Constants.BUCKET_NAME,file.getName(),
file);
//设置上传监听
observer.setTransferListener(new UploadListener());
//监听类
private class UploadListener implements TransferListener {
// Simply updates the UI list when notified. 上传失败监听
@Override
public voidonError(intid,Exception e) {
Log.e(TAG,"Error during upload: "+ id,e);
updateList();
}
//上传进度监听
@Override
public voidonProgressChanged(intid, longbytesCurrent, longbytesTotal) {
Log.d(TAG,String.format("onProgressChanged: %d, total: %d, current: %d",
id,bytesTotal,bytesCurrent));
updateList();
}
//上传状态监听
@Override
public voidonStateChanged(intid,TransferState newState) {
Log.d(TAG,"onStateChanged: "+ id +", "+ newState);//例如:UploadActivity: onStateChanged: 9, FAILD 失败状态
// //根据id 查询文件路径
// TransferObserver transferObserver = transferUtility.getTransferById(id);
// Log.d(TAG, "文件地址---"+transferObserver.getAbsoluteFilePath());
updateList();
}
}
-
4.源码简易流程图,数字代表行号:
aws sdk上传源码简易流程图
- 3.实现原理分析:
实际上AWS S3 存储协议只不过是添加一些跟服务端协商的请求头,请求头的value是用AWS s3 V4签名算法算出来的。所以,上传时带上指定的请求头,以及合法的签名算法,其他地方跟普通上传没区别。服务端拿到请求头后,根据合法的签名算法,计算签名值,然后跟客户端请求头里的签名进行校验,成功后,服务端才允许上传。
首先我们要解决两个问题: -
(1)指定的请求头有哪些?
-
首先我们来看一个文件上传的请求:
--------------------------请求头--------------------------
PUT /test/IMG_20170519_165644_1.jpg HTTP/1.1
Content-MD5: 6PN5Zj06z+D5UkSG1ZxhNA==
x-amz-decoded-content-length: 2566214
x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD
Content-Type: image/jpeg
X-Amz-Date: 20170522T024116Z
User-Agent: aws-sdk-android/2.4.2 Linux/3.10.86-g6be8ceb Dalvik/2.1.0/0 zh_CN TransferService/2.4.2
aws-sdk-retry: 0/0
Accept-Encoding: identity
aws-sdk-invocation-id: 148858f7-e319-4578-b9f8-1b220f6af380
Authorization: AWS4-HMAC-SHA256 Credential=1NA5K80UU85NMPK4BPEW/20170522/us-east-1/s3/aws4_request,SignedHeaders=content-md5;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length,Signature=db4e0abd4290730ed6fd27867d2fa342942372b88f1b5ad49b113ab9c77d6cc9
Content-Length: 2568100
Host: www.baidu.com
Connection: Keep-Alive
--------------------------------------请求体--------------
20000;chunk-signature=0cfa38451a889b866dbf43907ce3a72ee85f6b176168fb875903e8353366628e
。。。二进制文件流。。。
一大堆请求头,实际上根据 S3 API 文档,Authorization请求头才是必要的
而Authorization的value中SignedHeaders是规定了使用哪些请求头来计算本次请求的签名值。
注意:SignedHeaders还规定了请求头的顺序。后面计算签名流程图中Canonical Request拼接请求头的顺序与SignedHeaders必须保持一致。
也就是说content-md5;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length这些请求头计算出来Signature的值。根据S3 API 文档,SignedHeaders中host;x-amz-content-sha256;x-amz-date是必须存在的。
那为什么本次请求还要加上content-md5,x-amz-decoded-content-length这两个值?
我们来想想签名的作用:
- a.验证请求身份
ACCESSKEY、SecretKey就是用来验证身份的,这两个参数也是计算Authorization的value中Signature的值所必须的。
- a.验证请求身份
- b.防止篡改
SignedHeaders就是用来设置防止篡改的请求头的,content-md5是防止篡改请求内容(body),x-amz-decoded-content-length防止篡改请求内容长度的。
官方文档中,SignedHeaders必须的host;x-amz-content-sha256;x-amz-date这几个也就可以理解了,防止篡改请求地址,请求内容的sha256值,请求时间戳
- b.防止篡改
- c.防止请求签名被盗用
根据AWS S3 存储协议,时间戳(x-amz-date或Date请求头)15分钟内有效,没有权限的用户t通过截获已签名的request,可以篡改SignedHeaders中没有包含的部分,所以官方建议,签名所有请求头和请求体(也就是说SignedHeaders要尽量包含所有),还有最好用Https.
- c.防止请求签名被盗用
总结:
啰嗦一大堆,必要的请求头有哪些:Authorization、SignedHeaders中包含的(必须包含的有host;x-amz-content-sha256;x-amz-date),host,x-amz-content-sha256,x-amz-date这些请求头是服务端校验签名必须的。
-
(2)签名算法是如何计算的?(即Authorization中的Signature)
-
有两种签名算法:
-
第一种,单块传输(本人demo中使用的这种方式)
文件内存读取两次(一次计算文件sha256时,一次文件上传时)
单块上传请求头:
x-amz-content-sha256: 32e820d03db121caf97206f8cbcc6202cf25bf59246e8d6b0e8f6e3502d68f66
或:x-amz-content-sha256: UNSIGNED-PAYLOAD(这种是单块不进行签名内容的写法)
a.
单块上传签名计算流程
-
功能函数说明:
Lowercase():字符串转成小写.
Hex():base 16编码(全部小写).
SHA256Hash():计算请求体body(上传文件时,body中只有文件,即计算文件的SHA256)的SHA256,然后base64.
HMAC-SHA256():通过将key使用SHA256计算 HMAC
public static byte[]sumHmac(byte[] key, byte[] data)
throwsNoSuchAlgorithmException,InvalidKeyException {
Mac mac = Mac.getInstance("HmacSHA256");
mac.init(newSecretKeySpec(key,"HmacSHA256"));
mac.update(data);
returnmac.doFinal();
}
Trim():去空格.
UriEncode():
a.保持'A'-'Z','a'-'z', '0'-'9', '-', '.', '_', '~'不变
b.空格字符必须转成"%20" (而不是 "+")
c.byte编译成“%”后面跟两位的十六进制(字母大写)
d.如果文件名(object name)类似“photos/Jan/sample.jpg”,其中包含“/”,不进行转义。
public static String UriEncode(CharSequence input, boolean
encodeSlash) {
StringBuilder result = new StringBuilder();
for (int i = 0; i < input.length(); i++) {
char ch = input.charAt(i);
if ((ch >= 'A' && ch <= 'Z') || (ch >= 'a'
&& ch <= 'z') || (ch >= '0' && ch <= '9') || ch == '_' ||
ch == '-' || ch == '~' || ch == '.') {
result.append(ch);
} else if (ch == '/') {
result.append(encodeSlash ? "%2F" : ch);
} else {
result.append(toHexUTF8(ch));
}
}
return result.toString();
}
- 第二种,多块传输
多块上传请求头:
x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD
把有效荷载(请求body)分成几块,固定或可变大小的块。通过上传块,避免读取整个文件的有效荷载来计算签名.
- 第二种,多块传输
- a.第一块,计算所有的请求头的签名,空body请求
- b.第二块,将第一个块的签名和有效载荷一起计算签名
- c.第n块,将第n-1块的签名和有效载荷一起计算签名
-
d.最后,发送0 bytes的块包含第n块的签名。
请求头Authorization中的Signature计算同单块上传:
多块上传签名计算流程图
-
请求体中块签名计算:
请求体中比单块上传多了这些
chunk-signature的签名计算流程图
终于,说完了,第一次写这么长,讲的有不清楚的多多包涵,有什么问题可以给我留言,也可以发我邮箱18514689920@163.com.