在STS协同VOD、BOS服务中几个容易忽视的地方：

1. 用户申请STS的时候，需要带上ACL权限以访问BOS。否则获取的STS只能访问VOD的接口，无法访问BOS。如果带上ACL权限向BOS申请STS，获得到的STS ak/sk/token可以同时访问VOD服务的部分接口和BOS中的ACL规定的接口。

2. 用户申请STS的时候，ACL权限需要关注和理解。这是一个常见的ACL：

   {
     "accessControlList": [
       {   
         "service":"bce:bos",
         "region":"bj",
         "effect": "Allow",
         "resource": ["vod-gcqgg7xk0eqr78je/*"],
         "permission": ["WRITE"]
       }
     ]
   }

   根据STS文档，这里可以申请一个对BOS服务的bj区域的vod-gcqgg7xk0eqr78je下的任何object有写权限（WRITE ONLY）的STS ak/sk/token。

   通过VOD的三步上传法，其中对普通用户，VOD的申请媒资接口固定的返回一个bucket。所以用户可以先调用一次申请媒资接口，拿到其中的bucket值并填写在这里。这样用户产生的STS ak/sk/token就可以且仅对该bucket有写权限，对用户自己BOS中的bucket则没有任何权限。

3. STS是有失效时间的——这一点不难理解，如果STS是永久有效的，那么安全性会大打折扣。所以服务端有两种策略产生STS：

   1. 每次用户请求页面，都产生一个STS ak/sk/token填充到JS中。这样做的优点是，对每个客户分配一个不同的STS ak/sk/token，以备追查；缺点是服务器端压力比较大；
   2. 服务器端定期向STS申请ak/sk/token放入缓存中，并在失效之前若干时间再次申请并替换掉缓存，每个客户访问时候都给当前缓存中的值。两种方案各有优缺点，客户可以根据实际情况进行使用。

但是无论哪种方案，都无法避免客户端超时现象，即客户端在请求了3in1.js之后，X小时（X大于STS的失效时间）才开始在这个页面上进行操作。这个情况需要用户自行处理，比如设置登录超时、页面自动刷新等的方式让客户端主动更新3in1.js。另外尤其需要注意的是如果你的网站接入了CDN，可能需要针对性设置合适的CDN缓存时间以避免CDN缓存。