oss上传判断_OSS

前言

本文档是阿里云存储服务(OSS)的开发帮助指南，描述了OSS中的基本概念、提供的服务以及可用的API。

阿里云存储服务(OpenStorageService，简称OSS)，是阿里云对外提供的海量，安全，低成本，高可靠的云存储服务。用户可以通过简单的REST接口，在任何时间、任何地点、任何互联网设备上进行上传和下载数据，也可以使用WEB页面对数据进行管理。同时，OSS提供Java、

Python、 PHP、C#语言的SDK，简化用户的编程。基于OSS，用户可以搭建出各种多媒体分享网站、网盘、个人和企业数据备份等基于大规模数据的服务。

在OSS中，用户操作的基本数据单元是Object。单个Object最大允许存储5TB的数据。Object包含key、meta和data。其中，key是Object的名字；meta是用户对该object的描述，由一系列name-value对组成；data是Object的数据。

nObject命名规范

Ø使用UTF-8编码

Ø长度必须在1-1023字节之间

Ø不能以“/”或者“\”字符开头

Bucket是OSS上的命名空间，也是计费、权限控制、日志记录等高级功能的管理实体；Bucket名称在整个OSS服务中具有全局唯一性，且不能修改；存储在OSS上的每个Object必须都包含在某个Bucket中。一个应用，例如图片分享网站，可以对应一个或多个Bucket。一个用户最多可创建10个Bucket，但每个Bucket中存放的Object的数量和大小总和没有限制，用户不需要考虑数据的可扩展性。

nBucket命名规范

Ø只能包括小写字母，数字，短横线(-)

Ø必须以小写字母或者数字开头

Ø长度必须在3-63字节之间

2.3Access Key ID、Access KeySecret

用户注册OSS时，系统会给用户分配一对Access Key ID和Access Key Secret，称为ID对，用于标识用户，为访问OSS做签名验证。

OSS提供给用户的虚拟存储空间，在这个虚拟空间中，每个用户可拥有一个到多个Bucket。

1.

2.

3.

OSS为用户提供数据存储服务，用户可以通过以下操作来处理OSS上的数据：

n创建、查看、罗列、删除Bucket

n修改、获取Bucket的访问权限

n上传、查看、罗列、删除、批量删除Object

n对于大文件支持分片上传(Multi-Part Upload)

n访问时支持If-Modified-Since和If-Match等HTTP参数

3.2Object外链地址的构成规则

如果一个bucket设置成公开读权限(详见下一章：访问控制)，意味着你允许其他用户来访问属于你的object。你的object的外链地址构成规则如下：

http:// .oss.aliyuncs.com/

例如，在一个名为oss-example的bucket中，有一个名为"aliyun-log.png"的object(content-type为image/png)。那么这个object的外链URL为：

构成规则的示意图如下：

用户可以直接该URL链接放入HTML中使用：

src="http://oss-example.oss.aliyuncs.com/aliyun-logo.png"/>

OSS是按使用收费的服务，为了防止用户在OSS上的数据被其他人盗链，OSS支持基于HTTP header中表头字段referer的防盗链方法。目前，只有通过OSS的控制台(http://oss.aliyun.com)可以对一个bucket设置referer字段的白名单和是否允许referer字段为空的请求访问。例如，对于一个名为oss-example的bucket，设置其referer白名单为中的Object。

细节分析：

1)用户只有通过URL签名或者匿名访问Object时，才会做防盗链验证。请求的Header中有“Authorization”字段的，不会做防盗链验证。

2)一个bucket可以支持多个referer参数，这些参数之间由“，”号分隔。

3)Referer参数支持通配符“*”和“？”。

4)用户可以设置是否允许referer字段为空的请求访问。

5)白名单为空时，不会检查referer字段是否为空(不然所有的请求都会被拒绝)。

6)白名单不为空，且设置了不允许referer字段为空的规则；则只有referer属于白名单的请求被允许，其他请求(包括referer为空的请求)会被拒绝。

7)如果白名单不为空，但设置了允许referer字段为空的规则；则referer为空的请求和符合白名单的请求会被允许；其他请求都会被拒绝。

8)Bucket的三种权限(private，public-read，public-read-write)都会检查referer字段。

注意：OSS更多的防盗链的规则正在开发中。

3.4自定义域名绑定(CNAME)

OSS支持用户将自定义的域名绑定在属于自己的bucket上面，这个操作必须通过OSS控制台(http://oss.aliyun.com)来实现。按照中国《互联网管理条例》的要求，所有需要开通这项功能的用户，必须提供阿里云备案号，域名持有者身份证等有效资料，经由阿里云审批通过后才可以使用。在开通CNAME功能后，OSS将自动处理对该域名的访问请求。

CNAME应用场景例子：

Ø用户A拥有一个域名为abc.com的网站；这个网站的所有图片存储在img.abc.com这个子域名下；

Ø为了应对日益增长的图片流量压力，用户A在OSS上创建了一个名为abc-img的bucket，并将所有图片存在OSS上；

Ø通过OSS控制台，提交将img.abc.com CNAME成abc-img.oss.aliyuncs.com的申请，并提供相应的材料

Ø通过阿里云审核后，在自己的域名服务器上，添加一条CNAME规则，将img.abc.com映射成abc-img.oss.aliyuncs.com，这样所有对img.abc.com的访问都将变成访问abc-img这个bucket。例如：一个对的访问，实际上访问的是。

3.5访问日志记录[2](Server Access Logging)

OSS为用户提供自动保存访问日志记录功能。Bucket的拥有者可以通过OSS控制台(http://oss.aliyun.com)，为其所拥有的bucket开启访问日志记录功能。当一个bucket(源Bucket，Source Bucket)开启访问日志记录功能后，OSS自动将访问这个bucket的请求日志，以小时为单位，按照固定的命名规则，生成一个Object写入用户指定的bucket(目标Bucket，Target Bucket)。

存储访问日志记录的object命名规则：

-YYYY-mm-DD-HH-MM-SS-UniqueString

命名规则中，TargetPrefix由用户指定；YYYY,mm,DD,HH,MM和SS分别是该Object被创建时的阿拉伯数字的年，月，日，小时，分钟和秒(注意位数)；UniqueString为OSS系统生成的字符串。一个实际的用于存储OSS访问日志的Object名称例子如下：

MyLog-oss-example-2012-09-10-04-00-00-0000

上例中，“MyLog-”是用户指定的Object前缀；“oss-example”是源bucket的名称；“2012-09-10-04-00-00”是该Object被创建时的北京时间；“0000” 是OSS系统生成的字符串。

LOG文件格式(从左至右，以空格分隔)：

名称

例子

含义

Remote IP

119.140.142.11

请求发起的IP地址(Proxy代理或用户防火墙可能会屏蔽该字段)

Reserved

-

保留字段

Reserved

-

保留字段

Time

[02/May/2012:00:00:04

+0800]

OSS收到请求的时间

Request-URI

“GET /aliyun-logo.png

HTTP/1.1“

用户请求的URI(包括query-string)

HTTP Status

200

OSS返回的HTTP状态码

SentBytes

5576

用户从OSS下载的流量

RequestTime (ms)

71

完成本次请求的时间(毫秒)

Referrer

http://oss.aliyun.com

请求的HTTP Referrer

User-Agent

curl/7.15.5

HTTP的User-Agent头

HostName

oss-example.oss.aliyuncs.com

请求访问域名

Request ID

505B01695037C2AF032593A4

用于唯一标示该请求的UUID

LoggingFlag

true

是否开启了访问日志功能

Reserved

-

保留字段

Requester Aliyun ID

1657136103983691

请求者的阿里云ID；匿名访问为“-”

Operation

GetObject

请求类型

Bucket

oss-example

请求访问的Bucket名字

Key

/aliyun-logo.png

用户请求的Key

ObjectSize

5576

Object大小

Server Cost Time (ms)

17

OSS服务器处理本次请求所花的时间(毫秒)

Error Code

NoSuchBucket

OSS返回的错误码

UserID

1657136103983691

Bucket拥有者ID

Delta DataSize

280

Bucket大小的变化量；若没有变化为“-”

细节分析：

1)源Bucket和目标Bucket必须属于同一个用户。

2)“TargetPrefix”表示存储访问日志记录的object名字前缀，可以为空。

3)源bucket和目标bucket可以是同一个Bucket，也可以是不同的Bucket；用户也可以将多个的源bucket的LOG都保存在同一个目标bucket内(建议指定不同的TargetPrefix)。

4)OSS以小时为单位生成bucket访问的Log文件，但并不表示这个小时的所有请求都记录在这个小时的LOG文件内，也有可能出现在上一个或者下一个LOG文件中。

5)OSS生成的Log文件命名规则中的“UniqueString”仅仅是OSS为其生成的UUID，用于唯一标识该文件。

6)OSS生成一个bucket访问的Log文件，算作一次PUT操作，并记录其占用的空间，但不会记录产生的流量。LOG生成后，用户可以按照普通的Object来操作这些LOG文件。

7)OSS会忽略掉所有以“x-”开头的query-string参数，但这个query-string会被记录在访问LOG中。如果你想从海量的访问日志中，标示一个特殊的请求，可以在URL中添加一个“x-”开头的query-string参数。如：

http://oss-example.oss.aliyuncs.com/aliyun-logo.png

http://oss-example.oss.aliyuncs.com/aliyun-logo.png?x-user=admin

OSS处理上面两个请求，结果是一样的。但是在访问LOG中，你可以通过搜索“x-user=admin”，很方便地定位出经过标记的这个请求。

8)OSS的LOG中的任何一个字段，都可能出现“-”，用于表示未知数据或对于当前请求该字段无效。

9)根据需求，OSS的LOG格式将来会在尾部添加一些字段，请开发者开发Log处理工具时考虑兼容性的问题。

OSS通过使用Access Key ID/ Access Key Secret对称加密的方法来验证某个请求的发送者身份。Access Key ID用于标示用户，Access Key Secret是用户用于加密签名字符串和OSS用来验证签名字符串的密钥，其中Access Key Secret必须保密，只有用户和OSS知道。每个ACCESS Key对(Access Key ID和Access Key Secret)都有active/inactive两种状态。

nactive表明用户可以用此ID对签名验证请求

ninactive表明用户暂停此ID对签名验证的功能

一个用户可以同时拥有0至2个active或者inactive的ID对。用户可以登录http://oss.aliyun.com/，在OSS管理控制台申请新增或删除ID对。

当用户想以个人身份向OSS发送请求时，需要首先将发送的请求按照OSS指定的格式生成签名字符串；然后使用Access Key Secret对签名字符串进行加密产生验证码。OSS收到请求以后，会通过Access Key ID找到对应的Access Key Secret，以同样的方法提取签名字符串和验证码，如果计算出来的验证码和提供的一样即认为该请求是有效的；否则，OSS将拒绝处理这次请求，并返回HTTP 403错误。

用户可以在HTTP请求中增加Authorization(授权)的Head来包含签名(Signature)信息，表明这个消息已被授权。

Authorization字段计算方法如下：

"Authorization: OSS

" + Access Key ID + ":" + Signature

Signature = base64(hmac-sha1(VERB

+ "\n"

+

CONTENT-MD5 + "\n"

+

CONTENT-TYPE + "\n"

+

DATE + "\n"

+

CanonicalizedOSSHeaders

+

CanonicalizedResource))

nCONTENT-MD5表示请求内容数据的MD5值

nCONTENT-TYPE表示请求内容的类型

nDATE表示此次操作的时间，且必须为HTTP1.1中支持的GMT格式

nCanonicalizedOSSHeaders表示http中的object meta组合

nCanonicalizedResource表示用户想要访问的OSS资源

其中，DATE和CanonicalizedResource不能为空；如果请求中的DATE时间和OSS服务器的时间差正负15分钟以上，OSS服务器将拒绝该服务，并返回HTTP 403错误。

构建CanonicalizedOSSHeaders的方法：

所有以“x-oss-”为前缀的HTTP Header被称为CanonicalizedOSSHeaders。它的构建方法如下：

1)将所有以“x-oss-”为前缀的HTTP请求头的名字转换成小写字母。如’X-OSS-Meta-Name: TaoBao’转换成’x-oss-meta-name: TaoBao’。

2)将上一步得到的所有HTTP请求头按照字典序进行升序排列。

3)如果有相同名字的请求头，则根据标准RFC 2616, 4.2章进行合并(两个值之间只用逗号分隔)。如有两个名为’x-oss-meta-name’的请求头，对应的值分别为’TaoBao’和’Alipay’，则合并后为：’x-oss-meta-name:TaoBao,Alipay’。

4)删除请求头和内容之间分隔符两端出现的任何空格。如’x-oss-meta-name: TaoBao,Alipay’转换成：’x-oss-meta-name:TaoBao,Alipay’。

5)将所有的头和内容用’\n’分隔符分隔拼成最后的CanonicalizedOSSHeader。

构建CanonicalizedResource的方法：

用户发送请求中想访问的OSS目标资源被称为CanonicalizedResource。它的构建方法如下：

1)将CanonicalizedResource置成空字符串(“”)；

2)放入要访问的OSS资源：“ /BucketName/ObjectName”(无ObjectName则不填)

3)如果请求的资源包括子资源(sub-resource)[3]，那么将所有的子资源按照字典序，从小到大排列并以’&’为分隔符生成子资源字符串。在CanonicalizedResource字符串尾添加“？”和子资源字符串。此时的CanonicalizedResource例子如：/BucketName/ObjectName?acl &uploadId=UploadId

4)如果用户请求在查询字符串(query string)中指定了要重写(override)返回请求的header[4]，那么将这些查询字符串及其请求值按照字典序，从小到大排列，以’&’为分隔符，按参数的字典序添加到CanonicalizedResource中。此时的CanonicalizedResource例子：

/BucketName/ObjectName?acl&response-content-type=ContentType

& uploadId =UploadId

例如：想签名以下信息：

PUT /nelson HTTP/1.0

Content-Md5:

c8fdb181845a4ca6b8fec737b3581d76

Content-Type:

text/html

Date: Thu, 17 Nov 2005

18:49:58 GMT

Host: oss-example.oss.aliyuncs.com

X-OSS-Meta-Author:

foo@bar.com

X-OSS-Magic:

abracadabra

假如Access Key ID是："44CF9590006BF252F707"

Access Key

Secret是"OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV"，可用以下方法签名(Signature):

python示例代码：

import base64

import hmac

import sha

h =

hmac.new("OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV",

"PUT\nc8fdb181845a4ca6b8fec737b3581d76\ntext/html\nThu, 17 Nov

2005 18:49:58 GMT\nx-oss-magic:abracadabra\nx-oss-meta-author:foo@bar.com\n/oss-example/nelson",

sha)

base64.encodestring(h.digest()).strip()

签名(Signature)计算结果应该为”63mwfl+zYIOG6k95yxbgMruQ6QI=”， 然后加上Authorization头来组成最后需要发送的消息：

PUT /nelson HTTP/1.0

Authorization: OSS

44CF9590006BF252F707: 63mwfl+zYIOG6k95yxbgMruQ6QI=

Content-Md5:

c8fdb181845a4ca6b8fec737b3581d76

Content-Type:

text/html

Date: Thu, 17 Nov 2005

18:49:58 GMT

Host: oss-example.oss.aliyuncs.com

X-OSS-Meta-Author:

foo@bar.com

X-OSS-Magic: abracadabra

在计算签名头的时候请遵循如下规则：

1)用来签名的字符串必须为UTF-8格式。含有中文字符的签名字符串必须先进行UTF-8编码，再与Access Key Secret计算最终签名。

3)content-type和content-md5在请求中不是必须的，但是如果请求需要签名验证，空值的话以换行符“\n”代替。

4)在所有非HTTP标准定义的header中，只有以“x-oss-”开头的header，需要加入签名字符串；其他非HTTP标准header将被OSS忽略(如上例中的x-oss-magic)。

5)以“x-oss-”开头的head在签名验证前需要符合以下规范：

Øhead的名字需要变成小写。

Øhead按字典序自小到大排序。

Ø分割head name和value的冒号前后不能有空格。

Ø每个Head之后都有一个换行符“\n”，如果没有Head，CanonicalizedOSSHeaders就设置为空。

细节分析：

1)如果传入的Access Key ID不存在或inactive，返回403 Forbidden。错误码：InvalidAccessKeyId。

2)若用户请求头中Authorization值的格式不对，返回400

Bad Request。错误码：InvalidArgument。

3)OSS所有的请求都必须使用HTTP 1.1协议规定的。其中，日期的格式有三种：

date1 = 2DIGIT SP month SP 4DIGIT; day month year (e.g., 02 Jun

1982)

date2 = 2DIGIT "-" month "-" 2DIGIT; day-month-year

(e.g., 02-Jun-82)

date3 = month SP ( 2DIGIT | ( SP 1DIGIT )); month day (e.g., Jun2)【注意“2”前面有两个空格】

上述这三种日期格式中，“天”所占位数都是“2 DIGIT”。因此，“Jun 2”、“2 Jun 1982”和“2-Jun-82”都是非法日期格式。

4)如果签名验证的时候，头中没有传入Date或者格式不正确，返回403

Forbidden错误。错误码：AccessDenied。

5)传入请求的时间必须在OSS服务器当前时间之后的15分钟以内，否则返回403 Forbidden。错误码：RequestTimeTooSkewed。

6)如果Access Key ID是active的，但OSS判断用户的请求发生签名错误，则返回403 Forbidden，并在返回给用户的response中告诉用户正确的用于验证加密的签名字符串。用户可以根据OSS的response来检查自己的签名字符串是否正确。

返回示例：

version="1.0" encoding="UTF-8"?>

SignatureDoesNotMatch

The

request signature we calculated does not match the signature you provided.

Check your key and signing method.

47

45 54 0a 0a 0a 57 65 64 2c 20 31 31 20 4d 61 79 20 32 30 31 31 20 30 37 3a 35

39 3a 32 35 20 47 4d 54 0a 2f 75 73 72 65 61 6c 74 65 73 74 3f 61 63 6c

1E446260FF9B10C2

oss.aliyuncs.com

y5H7yzPsA/tP4+0tH1HHvPEwUv8=

GET

Wed,

11 May 2011 07:59:25 GMT

/oss-example?acl

AKIAIVAKMSMOY7VOMRWQ

除了使用Authorization Head，用户还可以在URL中加入签名信息，这样用户就可以把该URL转给第三方实现授权访问。

URL中包含签名示例:

http://oss-example.oss.aliyuncs.com/oss-api.pdf?OSSAccessKeyId=44CF9590006BF252F707&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D

在URL中实现签名，必须至少包含Signature，Expires，OSSAccessKeyId三个参数。Expires这个参数的值是一个UNIX时间(自UTC时间1970年1月1号开始的秒数，详见)，用于标识该URL的超时时间。如果OSS接收到这个URL请求的时候晚于签名中包含的Expires参数时，则返回请求超时的错误码。例如：当前时间是1141889060，开发者希望创建一个60秒后自动失效的URL，则可以设置Expires时间为1141889120。

所有的OSS支持的请求和各种Head参数，在URL中进行签名的方法和上节介绍的签名算法基本一样。主要区别如下：

1)通过URL包含签名时，之前的Date参数换成Expires参数。

2)不支持同时在URL和Head中包含签名。

3)如果传入的Signature，Expires，OSSAccessKeyId出现不止一次，以第一次为准。

4)请求先验证请求时间是否晚于Expires时间，然后再验证签名。

URL中添加签名的python示例代码为：

import base64

import hmac

import sha

import urllib

h = hmac.new("OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV",

"GET\n\n\n1141889120\n/oss-example/oss-api.pdf",

sha)

urllib.quote_plus (base64.encodestring(h.digest()).strip())

细节分析：

1)使用在URL中签名的方式，会将你授权的数据在过期时间以内曝露在互联网上，请预先评估使用风险。

2)PUT和GET请求都支持在URL中签名。

3)在URL中添加签名时，Signature，Expires，