本文假设读者已对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授权 参考 的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的详细介绍可见 eg： 这里对current容器添加允许任何人读取的设定， X-Container-Read: .r:*
结果如下： 
第三，检查是否生效 首先查看一下current容器返回的http头部是否已经包含了X-Container-Read的信息：
可以清楚看到之前的PUT操作已经成功生效了，current容器下面有两个objects，接下来我们通过浏览器尝试访问 新建文本文档.txt，由于object之前没有设置好content-type，浏览器打开直接变成了下载模式了。