在用户身份验证成功后，我的auth服务器会生成一个令牌并将其传递给客户端。
文档说客户端必须添加以下标题：
X-Auth-CouchDB-UserName：username;
X-Auth-CouchDB-Roles ：以逗号分隔（，）的用户角色列表;
X-Auth-CouchDB-Token：身份验证令牌。
这是否意味着客户在每个请求中定义自己的角色？为什么他不能添加＆＃39; admin＆＃39;进入角色列表呢？
答案 0 :(得分：1)
客户端是指使用或请求服务器资源的任何内容。
＆＃34;客户＆＃34;在这种情况下是您的代理/身份验证服务器，而不是Web浏览器。 （文档可能会稍微澄清一下。）
所以，您的代理/身份验证服务器（CouchDB的客户端）应该根据需要设置该标头。
通过扩展，它还应该不传递从其客户端（可能是网络浏览器）收到的任何onchange标头。
答案 1 :(得分：0)
很好的观察。使用 JWT Authentication 似乎可以堵住这个漏洞，因为我的理解是整个令牌都已签名。
也就是说，在任何情况下都无法避免：
前者是不可避免的，因为这些插件的目的是委托身份验证。您要么信任代理（或 JWT 颁发者），要么禁用这些 authentication_handlers。
后者是例如OAuth 1 有点反对，因为整个请求都被签名了，人们不能简单地从早期泄露的请求中获取几个身份验证标头，然后将它们放在一个新的伪造请求上。应该检查随机数和时间戳字段以避免逐字重播先前的请求。 （所有这些都被丢弃在 OAuth 2 中，无论它是有价值的……甚至 OAuth 1 在实践中也有一些 notable loopholes……）
因此在实践中应该小心使用代理或 JWT 身份验证处理程序。假设围绕您的 CouchDB 和身份验证源绘制了各种“防火墙”，那么正如@Flimzy 的回答所提到的，防止意外的标头从该边界外向内传播——以及防止真实标头向外泄漏——应该可以减轻大多数潜在的滥用.