访问控制 -奇异果体育app竞彩官网下载

签名认证访问

百度智能云采用统一的api鉴权认证机制，详情请见鉴权认证机制。

原始ak/sk鉴权

原始ak/sk是指您在注册bos时，系统自动分配给您的，主要用于对用户的调用行为进行鉴权和认证，相当于百度智能云api专用的用户名及密码。您向bos发送的每个请求，都需要通过鉴权认证通过后，bos才会处理您的请求。

移动端场景使用原始ak/sk鉴权的交互过程如下图所示：

将您的原始ak/sk下发到移动端势必会存在一定的安全风险，因此，原始ak/sk鉴权方式只推荐您在测试过程中使用，正式提供服务时推荐您使用sts方式鉴权。

当您在授权的时候，建议严格遵循最小权限原则，限定用户执行受限的操作（如仅授权读操作）并设置访问指定前缀的资源，避免授予过大的权限，导致预期外的越权操作，造成数据安全风险。

临时授权访问

sts简介

bos可以通过sts机制实现第三方的临时授权访问。sts（security token service）是百度智能云提供的临时授权服务。通过sts，您可以为第三方用户颁发一个自定义时效和权限的访问凭证。第三方用户可以使用该访问凭证直接调用百度智能云的api访问百度智能云资源。

说明：

这里的第三方用户主要是指您所开发的应用程序的终端用户，例如，您是移动app开发者，您的app终端用户我们称为第三方用户。

以移动客户端访问bos服务为例：

如您是移动app开发者，您已开通bos服务，并且需要为您的app客户端提供访问bos服务的权限，那么您有如下两种方式为移动客户端实现鉴权：

sts鉴权

为了让移动终端能够便捷、安全地享受到bos服务，百度智能云研发了sts服务，来对移动场景下的安全需求进行支持。您无需开放自己的ak/sk，仅通过sts即可实现临时授权。

使用sts为app客户端临时授权的流程如下图所示：

1. 申请访问bos权限。

   app客户端访问bos资源，需向appserver申请访问权限。已经开通bos服务的appserver可以针对不同的app终端用户进行授权及访问资源限制。

2. 申请临时访问凭证。

   appserver需要向sts服务申请一个临时访问凭证。appserver通过调用sts的getsessiontoken()接口进行申请，同时需要指定资源访问权限和过期时间。getsessiontoken()的调用方法请参考getsessiontoken接口，sts服务详情请参考。

3. 返回sts凭证给appserver。

   sts处理申请后，返回给appserver一份临时的身份凭证（credential），包括临时访问密钥ak/sk， sessiontoken、失效时间和appserver的用户id等信息。appserver可以缓存sts凭证，当多个app客户端需要的权限相同时，可以直接把缓存的凭证颁发给客户端。

4. 返回sts凭证给app客户端。

   appserver将收到的sts凭证下发给app客户端，app客户端可以缓存sts凭证。当凭证失效时，app客户端需要向appserver重新申请有效访问凭证。

5. app客户端使用sts凭证访问bos资源。

   app客户端设备可以直接使用返回的sts凭证构造api请求直接访问bos资源，bos会感知sts访问凭证，并会依赖sts服务来验证访问凭证，正确响应用户请求。

使用sts的优点：

• 您不需要向第三方用户透露您的管理账号或ak/sk信息，您只需要向sts申请一个临时访问凭证并颁发给第三方用户即可，且这个访问凭证拥有的权限和有效期均可由您自己去定义。
• 您不需要关注该权限的撤销问题，临时访问凭证在过期后会自动失效。

getsessiontoken接口

接口描述

getsessiontoken接口用于临时授权访问时，请求返回一份临时的访问凭证（credential）。

权限说明

请求发起人需要具有合法的accesskeyid和secretaccesskey才能发起请求。

请求

• 请求语法

  post /v1/sessiontoken?durationseconds=durationseconds http/1.1
  host: sts.bj.baidubce.com
  date: 
  authorization:  
  {
   "id":"userid",
   "accesscontrollist": [
    {   
     "eid":,
     "service":"bce:bos",
     "region":"bj",
     "effect": "allow",
     "resource": ["bucketname/*"],
     "permission": ["read"]
     }
    ]
   } 

• 请求参数

  名称	参数位置	描述	默认值	是否必选
  durationseconds	query参数	临时访问凭证的有效时长，即一次请求sts后，在有效时长内可使用此临时访问凭证多次访问bos资源，不需要重复请求sts。数据类型：int。单位为秒，最长可指定为129600秒（36小时）。	43200（12小时）	否

• 请求头域

  名称	数据类型	描述	默认值	是否必选
  authorization	string	认证字符串，计算方法请参考。	-	是

• 请求元素

  本接口的请求元素是权限控制的主要部分。请求元素由一条或多条acl配置项组成，每条acl配置项间相互独立。

  名称	数据类型	描述	默认值	是否必选	父节点
  accesscontrollist	array	标识acl主体的开始，由一或多组acl配置项组成。	-	是	-
  effect	string	指定与该条acl配置项匹配的request能否执行，取值为allow或deny。allow表示可以执行；deny表示拒绝执行。	-	是	accesscontrollist
  eid	string	标识acl配置项的id 。	-	否	accesscontrollist
  id	string	acl的标识符。	-	否	-
  permission	array	acl配置项所影响的权限,可选值为read、write、list和getobject。	-	是	accesscontrollist
  region	string	acl配置项影响的区域，"*"表示所有区域。	-	是	accesscontrollist
  resource	array	acl配置项所影响的资源，支持通配符。如：/或/xxx*	-	是	accesscontrollist
  service	string	acl配置项影响的服务组件，"*"表示所有服务。	-	是	accesscontrollist

说明：

• 由于getsessiontoken的响应结果会包含sts凭证，强烈建议通过https协议调用。
• service：以bos服务为例，取值为"service":"bce:bos"。

• resource：当"service":"bce:bos"时，resource支持bucket和object。

  • 当resource为bucket时，其取值为。例如，"resource"：["sts-bucket-1"]；
  • 当resource为object时，其取值为。例如，"resource"： ["sts-bucket-1/object1"]；
  • 此外，resource还支持通配符 *，表示bucket下所有object。例如："resource"： ["sts-bucket-1/*"]。

• permission： bos奇异果体育app竞彩官网下载的服务支持read/write/list/getobject权限。每个权限对应一组api请求如下：

  • read权限对应的操作有：

    • getbucketlocation
    • headbucket
    • getobject
    • getobjectmeta
    • listparts

  • write权限对应的操作有：

    • putobject
    • postobjcet
    • initiatemultipartupload
    • uploadpart
    • completemultipartupload
    • appendobject
    • abortmultipartupload
    • deleteobject
    • deletemultipleobjects
    • fetchobject

  • list权限对应的操作有：

    • listobjects
    • listmultipartuploads

  • getobject权限对应的操作有：

    • getobject
    • getobjectmeta

注意：

• 如在请求元素中不指定acl，则默认返回的临时权限credential与您当前拥有的read/write权限相同，授权给第三方用户后，可能会给您的账户资源带来风险，建议您在临时授权时明确指定acl，规避风险。如果请求body为空，则默认返回的sts凭证与您当前拥有的权限相同。
• 在您指定acl时，建议严格遵循，限定用户执行受限的操作（permission字段）并设置访问指定前缀的资源（resource字段），避免造成数据安全风险。

响应

• 响应头域

本接口只用到了公共响应头。

• 响应元素

示例

• 请求示例

  post /v1/sessiontoken?durationseconds=durationseconds http/1.1
  host: sts.bj.baidubce.com
  date: wed, 06 apr 2016 06:34:40 gmt
  authorization: authorizationstring
  content-type:application/json
  content-length:178
   {
    "id":"10eb6f5ff6ff4605bf044313e8f3ffa5",
    "accesscontrollist": [
     {   
      "eid":,
      "service":"bce:bos",
      "region":"bj",
      "effect": "allow",
      "resource": ["sts-bucket-1-140683201300192-1447847972462384520478/*"],
      "permission": ["read"]
      }
     ]
    }

• 响应示例

  http/1.1 200 ok
  server: apache-coyote/1.1
  content-type: application/json;charset=utf-8
  date: wed, 06 apr 2016 06:34:40 gmt
  {
    "accesskeyid": "3bdecf4afebd41849628389a20629ecc", 
    "secretaccesskey": "3f901ef12d454b9c92ba2dde7c029140", 
    "sessiontoken": "zgzim2m3mmu4mjk4ngq2mgezytnhytaymde3ntzmzmv8aaaaac8caabf0xcbs9e/leushxryz4dynb sh374s mmkxaopcwdlpc7jl/atf5f7x83dqn354vkitynguvqisv7midipn7 0ooehdflhua4rkwqii8woslx0qnitza56wpxowlprrmksohiqieqyezayavf3oy3hbbmix/rprtcnxerai1/sknr1vztzyyfs5d4p8ul62x9whwmj5lkxy6yuz1og94wytwtc8awpfpgfipqycpcaxyvl/qka1m0rxq6smahbxtyeyug2eg8eop0ekn2o2dmjgulurrkuxhrcrfidrxdqox9km/l7gqxuazl9ddb1dwzprso8xipdrrfkpiqvkjeeb0blb8dxtmm0v0lmtznurnpuod4nfvyepkcet 0jhqooxnlwde6x4alnr8qtjkj2yjryaomzdeuqkrcpgehvoigi8zdiumn1rdobs7a4hw4gmx7f0gqglwdif4zoksspwp8aos vzdoa nnshstvg==", 
    "createtime": "2015-11-18t11:48:17z", 
    "expiration": "2015-11-18t23:48:17z", 
    "userid": "2d6f4473c99e4ca7be1ca19ec18beacf"
  }

sts鉴权过程

当第三方用户使用返回的临时ak/sk以及sessiontoken向百度智能云的服务端发起请求时，服务端是如何完成临时鉴权验证的呢？

1. 首先，服务端会验证请求的合法性。

   服务器端会通过请求中的access key id找到对应的secret access key，并提取请求中的签名字符串和signature。如果服务器端计算出来的signature和请求中提供的signature一样，即认为该请求是合法的；否则认为该请求是非法的，将拒绝处理这次请求。

2. 然后，服务端会验证请求者是否对于资源有操作的权限。

   服务器端会将该次请求与申请临时token时getsessiontoken携带的acl列表逐条对比，对比后的处理逻辑如下图：

举例说明：

假设在申请临时token时的acl如下：

[{
    "effect": "allow",
    "resource": ["sts-bucket-1"],
    "region": "bj",
    "service": "bce:bos",
    "permission": ["read"]
}],

被授权的第三方想要对sts-bucket-1下的img.jpg进行getobject操作。 由于getoject对应read权限，所以这次请求可以写成：

[{
    "resource": ["sts-bucket-1/img.jpg"],
    "region": "bj",
    "service": "bce:bos",
    "permission": ["read"]
}],

和上面的acl进行匹配时会失败，因为resource并不匹配。如果当时申请临时token时resource写成sts-bucket-1/img.jpg或sts-bucket-1/*则可以成功匹配。

使用sts凭证访问bos服务

app客户端拿到sts临时凭证后，通过其中session token以及临时访问密钥（ak/sk)构建签名。签名方式同签名认证访问。需要注意如下关键点：用户使用的签名密钥为sts提供的临时访问密钥(ak/sk)。

与普通的api接口相比，使用sts凭证调用api时，只需要在请求中增加x-bce-security-token: 即可，以putobject为例：

put /object http/1.1
host: .bos.bj.baidubce.com 
date: wed, 06 apr 2016 06:34:40 gmt 
authorization:  
x-bce-security-token: 
content-type: text/plain 
content-length: 11434 

说明：

• 目前sts只支持read、write、list、getobject 所对应的api请求。
• sts具有缓存机制，在有效时间内可使用同一访问凭证多次访问bos资源，不需要重复发送sts请求。通过修改请求中的durationseconds参数可调整临时访问凭证的有效时间。

bucket权限控制

权限控制概述

bos支持使用acl对bucket权限进行管理。bucket acl是附属于资源即某个bucket的权限，其本质上是授权谁（grantee）可以执行哪些操作（permission）。为了方便用户更精细地控制bucket里的资源，bucket acl支持resource和notresource字段。resource字段用于实现对指定范围的prefix和object粒度的权限控制，notresource字段用户实现对指定范围外的prefix和object粒度的权限控制。 此外，bucket acl还支持condition字段，condition字段可以用来设置访问者的ip、referer等信息。

为了保障您存储在bos中数据的高安全性，我们为您提供了丰富的多级权限管理能力。 bos的权限体系分为如下三级：

bucket标准权限（即cannedacl） 粗粒度自定义权限 细粒度自定义权限

bos目前可以通过上传acl文件和使用cannedacl两种方式来设置acl，两种方式都通过实现。上传acl文件是通过一个json文件来描述谁（grantee）在什么条件下（condition）可以对什么资源（resource或notresource）执行哪些操作（permission）。直接编辑acl文件门槛较高，因此bos还支持cannedacl方式。cannedacl本质上就是对几种常见的权限控制场景进行了封装，直接在putbucketacl的头域中的“x-bce-acl”字段对资源进行设置。

使用cannedacl方式的权限控制

cannedacl是一种方便用户使用的方式，对常见的几种权限情况进行了封装。通过在putbucketacl的头域中的“x-bce-acl”字段对该资源进行设置的。例：x-bce-acl:public-read。字段区分大小写。

当前支持的cannedacl包括：

说明：通过putbucket创建的新bucket权限默认是private。

上传acl文件方式的权限控制

acl文件格式

putbucketacl可以通过上传一个acl文件的方式对访问权限进行设置。bos acl使用json格式的策略描述语言，命名方法为首字母小写的驼峰命名格式，字段区分大小写。

bos acl内容可以使用获取权限配置模板及自定义配置。

字段总览：

说明：

• 所使用的acl格式如上所述；在上传acl文件时，可不带owner属性(json字段标识bucket的owner)；如果带有owner属性，则其id值必须为bucket的owner id
• 上传的acl文件不大于20kb。
• 若用户使用putbucketacl接口的时候，在http报文的header(canned acl)和body中同时设置了acl，则返回错误码400，错误说明为“参数不正确”。
• 设置currenttime子字段值时，设置的是gmt时间，注意与本地时间的差别。
• 在一条acl规则中，同时只能存在一个resource或一个notresource的设置。

bucket acl支持粗粒度自定义权限

permission本质上对应一组bos api操作。bos api分为bucket级别api和object级别的api，如listobjects用来查看一个bucket中的所有object列表，是一个bucket级别api，putobject用来上传一个文件，是一个object级别api。 所以在acl文件里，当设置好permission后，需要设定相应的resource或notresource。缺省情况下resource字段不填或填bucket名称，就可以同时匹配bucket级别和object级别的所有操作。

bucket acl支持如下粗粒度自定义权限：

bucket acl支持细粒度自定义权限

为了保障您存储在bos中数据的高安全性和满足您对bos资源更加细粒度的进行权限访问控制，bos在支持read、list、write、modify、full_control这几种粗细粒度的基础上，现在扩展支持了各类细粒度权限。

bucket相关权限说明如下：

object相关权限说明如下：

说明：

• 新增的粗细粒度和以前的read、list、write、full_control、modify、getobject、restoreobject这几种粗细粒度互不影响，其中read，write，list，full_control， modify属于粗粒度权限。
• 粗粒度权限高于细粒度权限，如果既配了粗粒度权限又配了细粒度权限，粗粒度权限会覆盖细粒度权限，以粗粒度为主。
• bucket级别的细粒度是指对bucket进行的相关操作。
• object级别的细粒度是指对object进行的相关操作。

bucket acl支持deny和数据防篡改

bucket acl同时支持effect字段，用于设置该条权限的效果，effect支持allow和deny这两种配置方式。

说明：

• 在不配置effect的情况下，默认情况下是隐式allow。在配置effect的情况下，当值为allow时是显式allow；在不配置effect和配置effect并且其值为allow的况下，这两种情况是等价的。
• deny的语义高于allow，当用户既配了allow也配了deny的情况下，以deny为准，拒绝通过；deny了粗粒度权限，不管细粒度权限是否允许，都不允许通过。
• allow了粗粒度权限，但是deny了细粒度权限，那么就取粗粒度与细粒度的差集，差集部分的操作是允许通过的。
• 目前read、list、write、full_control、modify权限为粗粒度权限，其余的权限可以归结为细粒度权限。

为了解决由于密钥泄露、权限控制不严格、操作失误等带来的数据删除、篡改风险，bos推出bucket数据防篡改的功能，通过在bucket acl设置modify粗粒度权限和deny关键字组合就可以起到bucket数据防篡改的效果。

目前涉及到写的粗粒度有write、full_control、modify，细粒度有putobject、renameobject、deleteobject。

modify的使用方式主要有两大类，allow和deny这两种。

说明：

• 写操作，包括新增操作、覆盖操作和删除操作，新增操作是指：新上传一个object，这个object以前是不存在的，覆盖操作是指：上传一个object，这个object以前是存在的。
• modify粗粒度写权限包含renameobject细粒度写权限和putobject细粒度写权限下面的部分操作，如putobject、postobject、appendobject、copyobject、fetchobject、multiuploadinitobject等
• 如果配置允许了putobject、renameobject、deleteobject、write、full_control几种写粒度之中的任意一种，并且没有配置deny modify，那么允许用户进行正常的写操作。

allow的示例如下表所示:

deny的示例如下表所示

数据安全提示：

在您为用户授权时，建议严格遵循，限定用户执行受限的操作并设置访问指定前缀的资源，避免授予过大的权限，导致预期外的越权操作，造成数据安全风险。包括但不限于以下典型场景：

• 粗粒度自定义权限list、write操作的安全风险较高，不建议向所有用户授权该操作，可通过配置grantee字段标识被授权人。
• 授权write操作时，建议避免授权bucket级别的写权限，建议配置resource字段值精确到bucketname/objectname/*。
• 自定义粗粒度权限中，read权限允许读取bucket内的object及其相关信息，但没有列表权限，list权限为列表权限，可以查看指定bucket下的object列表以及获取所有未执行完的multipartupload。建议区分read权限和list权限支持的操作范围，在最小范围内为用户分配权限。
• 多用户共同使用同一个bucket时，建议通过划分bucket区域的方式明确用户可访问的资源，授权时精确到bucketname/userid/*。

请求授权过程

使用acl对bucket进行权限管理时，每个bucket只能有一个acl文件，但每个acl里可以有一组或多组acl配置项用来定义不同用户对不同资源拥有不同操作权限，accesscontrollist字段用来标识acl主体的开始。acl文件中的每组acl配置项由grantee permission resource（或notresource） condition组合而成，如果某个请求能成功授权则需要匹配一组acl配置项中的所有条件。当一条请求过来时会逐个匹配acl中的配置项，只要某组acl配置项中有一个条件没有匹配上则不能通过授权，除非一组acl配置项中的所有条件匹配上才能完成授权。acl授权过程如下图：

假定此时acl文件定义的grantee是*即所有用户，permission是read，resource是bucket1。

• 如果请求为putobject即上传文件cat.jpg到bucket1中，该请求会被拒绝，因为putobject不属于read permission所包含的api，所以请求不能通过。
• 如果请求为getobject即从bucket1中下载文件cat.jpg，该请求可以通过授权，因为getobject对应的permission是read，匹配acl中的所有条件，所以通过授权。

说明: copyobject操作，需要对源object有read、getobject或full_control权限，对目标object有write或full_control权限。

示例

• 该示例主要讲解grantee和permission的基础用法。

  假设bucket1的owner希望让另一个百度智能云用户（userid=16147f559dd14bb294175a8bab74ff1f）帮助自己管理bucket1，即设置该用户对bucket1拥有full_control权限，对应的acl文件格式如下：

  {
      "accesscontrollist": [
          {
              "grantee": [
                  {
                      "id": "16147f559dd14bb294175a8bab74ff1f"
                  }
              ],
              "permission": [
                  "full_control"
              ]
          }
      ]
  }

• 该示例主要讲解多个acl配置项的使用方法。

  bucket1的owner希望所有人都可以读取bucket的内容，但只有一个百度智能云用户（userid=b124deeaf6f641c9ac27700b41a350a8）能够管理bucket，则设置所有用户为read权限，而userid=b124deeaf6f641c9ac27700b41a350a8的用户为full_control权限。对应的acl文件格式如下：

        {
            "accesscontrollist": [
                {
                    "grantee": [
                        {
                            "id": "b124deeaf6f641c9ac27700b41a350a8"
                        }
                    ],
                    "permission": [
                        "full_control"
                    ]
                },
                {
                    "grantee": [
                        {
                            "id": "*"
                        }
                    ],
                    "permission": [
                        "read"
                    ]
                }
            ]
        }

• 该示例主要讲解condition字段的使用方法。

  bucket1的owner允许通过特定ip段的userid=10eb6f5ff6ff4605bf044313e8f3ffa5的用户来管理bucket，则通过condition定义ip地址段，并授权这些用户full_control权限。对应的acl文件格式如下：

        {
          "accesscontrollist": [
              {
                  "grantee": [
                      {
                          "id":"10eb6f5ff6ff4605bf044313e8f3ffa5"
                      }
                  ],
                  "permission": [
                      "full_control"
                  ],
                  "condition" : {
                    "ipaddress": [
                          "192.168.0.0/16",
                          "192.169.0.*",
                          "192.170.0.5"
                      ]
                  }
              }
          ]
        }

• 该示例主要讲解condition的securetransport和currenttime字段的使用方法。

  bucket1的owner只允许通过https方式在指定时间访问的userid=10eb6f5ff6ff4605bf044313e8f3ffa5的用户来管理bucket，则通过condition定义securetransport、currenttime地址段，并授权这些用户full_control权限。对应的acl文件格式如下：

    {
       "accesscontrollist": [
            {
                "grantee": [
                    {
                        "id": "10eb6f5ff6ff4605bf044313e8f3ffa5"
                    }
                ],
                "permission": [
                    "full_control"
                ],
                "resource": [
                    "bucket1/*"
                ]，
                "condition": {
                    "currenttime": {
                        "datelessthan": "2020-07-01t12:00:00z" ,
                        "dategreaterthan": "2018-03-01t15:00:00z"
                    },
                    "securetransport": true
                }
            }
        ]
    }

• 该示例主要讲解referer字段的使用方法。

  bucket1的owner允许通过特定ip且referer与配置的白名单匹配的userid=c558855ea8514c299508699b115473ef的用户查看bucket和object信息。其中referer字段用来定义允许访问的白名单，stringequals用于精确匹配，stringlike用于模糊匹配。stringlike中*代表0到任意多的字符，最多可以有一个*，*可以在字符串的任意位置。对应的acl文件格式如下：

        {
           "accesscontrollist": [
                {
                    "condition": {
                        "referer": {
                            "stringlike": [
                                "http://www.abc.com/*"
                            ],
                            "stringequals": [
                                "http://www.abc.com"
                            ]
                        },
                        "ipaddress": [
                            "192.168.1.1"
                        ]
                    },
                    "grantee": [
                        {
                            "id": "c558855ea8514c299508699b115473ef"
                        }
                    ],
                    "permission": [
                        "list"
                    ],
                    "resource": [
                        "bucket1",
                        "bucket1/*"
                    ]
                }
            ]
        }

• 该示例主要讲解resource字段的使用方法。

  resource字段可以用来对bucket内的文件和目录（prefix）设置访问权限。 bucket1的owner只允许另一个百度智能云用户（userid=10eb6f5ff6ff4605bf044313e8f3ffa5）对“cook” 为前缀的object、“edu/” 为前缀的object和“travel/中国国家地理杂志”这个object有full_control权限。resource字段的末尾有且只能有一个*。由于resource字段所指定资源是object，所以只有full_control permission所包含的object级别的api操作（如putobject、getobject、deleteobject）会被执行。对应的acl文件格式如下：

        {
          "accesscontrollist": [
              {
                  "grantee": [
                      {
                          "id":"10eb6f5ff6ff4605bf044313e8f3ffa5"
                      }
                  ],
                  "permission": [
                      "full_control"
                  ],
                  "resource": [
                      "bucket1/cook*",
                      "bucket1/edu/*",
                      "bucket1/travel/中国国家地理杂志"
                  ]
              }
           ]
        }

• 该示例主要讲解notresource字段的使用方法。

  notresource字段可以用来对bucket内某些指定文件和目录（prefix）之外的object设置访问权限。bucket1的owner只允许另一个百度智能云用户（userid=10eb6f5ff6ff4605bf044313e8f3ffa5）对除“cook”为前缀的object、“edu/”为前缀的object和“travel/中国国家地理杂志”这个object之外的其它object有full_control权限。notresource字段的末尾有且只能有一个*。由于notresource所指定资源是object，所以只有full_control permission所包含的object级别的api操作（如putobject、getobject、deleteobject）会被执行。对应的acl文件格式如下：

         {
           "accesscontrollist": [
               {
                   "grantee": [
                       {
                           "id":"10eb6f5ff6ff4605bf044313e8f3ffa5"
                       }
                   ],
                   "permission": [
                       "full_control"
                   ],
                   "notresource": [
                       "bucket1/cook*",
                       "bucket1/edu/*",
                       "bucket1/travel/中国国家地理杂志"
                   ]
               }
            ]
         }

• 该示例主要讲解bucket级别的权限示例的基础用法。 bucket1的owner希望只有一个百度智能云用户（userid=b124deeaf6f641c9ac27700b41a350a8）能够查看bucket的信息或者列出bucket下面的object，则设置这个用户为getbucket权限。对应的acl文件格式如下：

{
    "accesscontrollist": [
        {
            "grantee": [
                {
                    "id": "b124deeaf6f641c9ac27700b41a350a8"
                }
            ],
            "permission": [
                "getbucket"
            ]
        }
    ]
}

• 该示例主要讲解object级别的权限示例的基础用法。

  bucket1的owner希望所有人都只可以对bucket里面的object进行读和写，但只有一个百度智能云用户（userid=b124deeaf6f641c9ac27700b41a350a8）能够管理bucket，则设置所有用户为getobject，putobject权限，而userid=b124deeaf6f641c9ac27700b41a350a8的用户为full_control权限。对应的acl文件格式如下：

    {
        "accesscontrollist": [
            {
                "grantee": [
                    {
                        "id": "b124deeaf6f641c9ac27700b41a350a8"
                    }
                ],
                "permission": [
                    "full_control"
                ]
            },
            {
                "grantee": [
                    {
                        "id": "*"
                    }
                ],
                "permission": [
                    "getobject"，"putobject"
                ]
            }
        ]
    } 

• 该示例主要讲解bucket防数据篡改示例的基础用法。

  bucket1的owner不希望一个百度智能云用户（userid=b124deeaf6f641c9ac27700b41a350a8）篡改bucket的数据，但是允许其新增数据和读取数据，则设置userid=b124deeaf6f641c9ac27700b41a350a8的用户权限为deny modify、allow putobject、allow read，对应的acl文件格式如下：

    {
    	"accesscontrollist": [
    		{	
    			"effect" : "deny",
    			"grantee": [
    				{
                        "id": "b124deeaf6f641c9ac27700b41a350a8"
                    }
                ],
                "permission": [
                    "modify"
                ]
            },{	
    			"effect" : "allow",
    			"grantee": [
    				{
                        "id": "b124deeaf6f641c9ac27700b41a350a8"
                    }
                ],
                "permission": [
                    "putobject","read"
                ]
            }
        ]
    }

查看访问权限

• 查看某bucekt的访问权限，详见。
• 返回的acl会自动加上owner属性。

object权限控制

bos支持使用acl对object权限进行管理。object acl是附属于资源即某个object的权限，其本质上是授权谁（grantee）可以执行哪些操作（permission）。

bos目前可以通过上传acl文件和使用cannedacl两种方式来设置acl，两种方式都可以通过实现。

• 上传acl文件是通过一个json文件来描述object acl信息。直接编辑acl文件门槛较高，因此bos还支持cannedacl方式。
• cannedacl本质上就是对几种常见的权限控制场景进行了封装，直接在putobjectacl的头域中的“x-bce-acl”字段或者x-bce-grant-read/x-bce-grant-full-control字段对资源进行设置。

object acl支持的permission权限

cannedacl支持类型

cannedacl支持的三种header

为了方便权限设置，在创建object、复制object及设置object acl时可以添加cannedacl，通过头域的"x-bce-acl"或者"x-bce-grant-permission'来设置object访问权限，目前不支持在同一请求中同时设置cannedacl和上传acl文件。主要有以下header设置方式, 两种类型的header不可以同时在一个请求中出现。

说明：

• 如果object是归档类型的文件，那么该文件在归档文件刚上传和取回过程完成前，不能设置和删除object acl配置。

可通过header修改canned acl的接口

• putobject接口