用户身份验证成功后，身份验证服务器将生成一个令牌并将其传递给客户端。文档说明客户端必须添加以下头：X验证治疗床数据库用户名：用户名;
X-Auth-CouchDB-Roles：用户角色的逗号分隔（，）列表;
X验证CouchDB令牌：身份验证令牌。
这是否意味着客户端在每个请求上都定义了自己的角色？为什么他不能将“admin”添加到角色列表中？
kgsdhlau1#
客户端是使用或请求服务器资源的任何对象。在这种情况下，“客户端”是您的代理/身份验证服务器，而不是Web浏览器。（文档可能需要澄清一下。）因此，是的，您的代理/身份验证服务器（CouchDB的客户端）应该适当地设置该头。通过扩展，它还应该 * 不 * 通过从 * 其 * 客户端（可能是Web浏览器）接收的任何X-Auth-Couch头。
X-Auth-Couch
4zcjmb1e2#
很好的观察。使用JWT身份验证似乎可以弥补这个漏洞，因为我的理解是整个令牌都已签署。也就是说，在这两种情况下都不能避免：
前者是不可避免的，因为这些插件的目的是委托身份验证。要么信任代理（或JWT发布者），要么禁用那些authentication_handlers。后者是OAuth 1等对其自身进行了某种程度的强化，因为整个请求都被签名了，我们不能简单地从之前泄露的请求中提取几个auth头，然后将它们添加到新的伪造请求中。我们还应该检查Nonce和timestamp字段，以避免逐字重放之前的请求。（所有这些都在OAuth 2中被删除了...甚至OAuth 1在实践中也有一些notable loopholes...）因此，在实践中，无论是Proxy还是JWT身份验证处理程序都应该小心使用。假设在CouchDB和身份验证源周围都有一个“防火墙”，那么正如@Flimzy的回答所提到的，防止意外的头从边界外进入，以及防止真实的的头向外泄漏，应该可以减少大多数潜在的滥用。
authentication_handlers
2条答案
按热度按时间kgsdhlau1#
客户端是使用或请求服务器资源的任何对象。
在这种情况下，“客户端”是您的代理/身份验证服务器，而不是Web浏览器。（文档可能需要澄清一下。）
因此，是的，您的代理/身份验证服务器（CouchDB的客户端）应该适当地设置该头。
通过扩展，它还应该 * 不 * 通过从 * 其 * 客户端（可能是Web浏览器）接收的任何
X-Auth-Couch头。4zcjmb1e2#
很好的观察。使用JWT身份验证似乎可以弥补这个漏洞，因为我的理解是整个令牌都已签署。
也就是说，在这两种情况下都不能避免：
前者是不可避免的，因为这些插件的目的是委托身份验证。要么信任代理（或JWT发布者），要么禁用那些
authentication_handlers。后者是OAuth 1等对其自身进行了某种程度的强化，因为整个请求都被签名了，我们不能简单地从之前泄露的请求中提取几个auth头，然后将它们添加到新的伪造请求中。我们还应该检查Nonce和timestamp字段，以避免逐字重放之前的请求。（所有这些都在OAuth 2中被删除了...甚至OAuth 1在实践中也有一些notable loopholes...）
因此，在实践中，无论是Proxy还是JWT身份验证处理程序都应该小心使用。假设在CouchDB和身份验证源周围都有一个“防火墙”，那么正如@Flimzy的回答所提到的，防止意外的头从边界外进入，以及防止真实的的头向外泄漏，应该可以减少大多数潜在的滥用。