本文假设读者已对OOS有一定的认识了解并且已经自行成功搭建过Swift,背景还有部署方法这里就不多说了,这里Swift使用的身份认证组件为Keystone,参照官方文档步骤操作发现,对container设置ACL后仍没法实现允许任何人访问该容器下的object。后来查看Swift中间件源码中的注释得知,只需在proxy-server.conf中启动相应配置即可解决上述问题。
首先来看看proxy-server.conf中的pipline顺序:
[pipeline:main]
pipeline = catch_errors healthcheck proxy-logging cache bulk slo ratelimit authtoken keystoneauth container-quotas account-quotas staticweb proxy-logging proxy-server
上面标红部分为keystone认证组件,在正常情况下,请求要顺利通过proxy-server,必须要从keystone或者cache中拿到一个有效token,然而要想拿到token的话,必须要输入Tenant、User和password等相关信息。这样来说,swift仅提供了私有存储的服务,要想实现公有存储服务,仍需做以下操作。
第一,修改proxy-server.conf配置
引用keystoneauth.py代码注释说明:
If support is required for unvalidated users (as with anonymous access) or for formpost/staticweb/tempurl middleware, authtoken will need to be configured with ``delay_auth_decision`` set to true.
[filter:authtoken]
...
delay_auth_decision = true
...
查看swift和keystone相关代码暂时没有弄懂这个设置是在哪里、通过哪一个逻辑判断生效的,通过字面意思可以看出,系统暂时延迟用户身份的认证,交由后面组件来把关是否Authentication required!
第二,对指定的Container设置ACL授权
参考 os-objectstorage-devguide-1.0.pdf 的4.8章节
在container的metadata元素当中,X-Container-Read有着特别重要的作用,它可以通过ACL授权指定谁可以直接读取该container当的所有objects,二在设定 X-Container-Read之前,ACL的逻辑规定访问请求是必须包含有一个有效的 X-Auth-Token,否则将无法进入访问!现在我们尝试设定X-Container-Read看看能否实现container下面objects对任何人可读。
关于X-Container-Read的详细介绍可见 http://docs.openstack.org/developer/swift/misc.html#id5
eg:
这里对current容器添加允许任何人读取的设定, X-Container-Read: .r:*
![](http://static.oschina.net/uploads/space/2013/0909/195011_qeMz_818881.png)
结果如下:
![](http://static.oschina.net/uploads/space/2013/0909/195420_cHoH_818881.png)
第三,检查是否生效
首先查看一下current容器返回的http头部是否已经包含了X-Container-Read的信息:
![](http://static.oschina.net/uploads/space/2013/0909/195936_d7Bh_818881.png)
可以清楚看到之前的PUT操作已经成功生效了,current容器下面有两个objects,接下来我们通过浏览器尝试访问 新建文本文档.txt,由于object之前没有设置好content-type,浏览器打开直接变成了下载模式了。
![](http://static.oschina.net/uploads/space/2013/0909/201609_1q6W_818881.png)