【发布时间】：2017-08-20 09:30:39
【问题描述】：
当用户认证成功时，我的认证服务器会生成一个令牌并将其传递给客户端。
文档说客户端必须添加以下标头：
X-Auth-CouchDB-UserName：用户名；
X-Auth-CouchDB-Roles：逗号分隔 (,) 的用户角色列表；
X-Auth-CouchDB-Token：身份验证令牌。
这是否意味着客户端在每个请求中都定义了自己的角色？那他为什么不能在角色列表中添加“管理员”呢？
【问题讨论】：
【发布时间】：2017-08-20 09:30:39
【问题描述】：
客户端是使用服务器或从服务器请求资源的任何东西。
在这种情况下，“客户端”是您的代理/身份验证服务器，而不是 Web 浏览器。 （文档可能需要澄清一下。）
所以是的，您的代理/身份验证服务器，即 CouchDB 的客户端，应该适当地设置该标头。
通过扩展，它还应该不通过从其客户端（可能是网络浏览器）接收到的任何X-Auth-Couch标头。
【讨论】：
-
您好 Flimzy，感谢您的澄清回答。我仍然不太确定，是否可以将代理身份验证机制与 3rd 方身份验证/用户数据库一起使用。我想，在我对服务器上的用户进行身份验证后，服务器可以依次向 couchdb 发送代理身份验证请求，并为用户（网络浏览器）提供生成的令牌，以便他与沙发数据库。但是，如果用户以后可以更改 Roles 标头，则该机制将毫无用处。还是我错过了什么？谢谢！
-
一种选择是通过代理服务器转发来自用户（pouchdb）的所有请求，这将简单地添加适当的标头..我认为这不是很好
-
如果您希望您的身份验证服务器为客户端提供身份验证令牌，只需让它发送一个标准的 CouchDB cookie。您可以让您的身份验证服务器创建与 CouchDB 的会话，然后将 cookie 转发到 Web 浏览器（以及正确的 CORS 配置）。或者，您可以让您的身份验证服务器创建一个 validCouchDB cookie as described here。
-
或者如您所料，您可以代理所有请求。是否执行取决于实现细节。
-
感谢您提供有用的链接，现在我将尝试使用代理中间件方法
良好的观察力。使用JWT Authentication 似乎可以弥补这个漏洞，因为我的理解是整个令牌都已签名。
也就是说，在任何一种情况下都无法避免：
- 必须完全信任持有机密的实体
- 必须小心防止其接头泄漏
前者是不可避免的，因为这些插件的目的是委托身份验证。您要么信任代理（或 JWT 发行者），要么将这些 authentication_handlers 禁用。
后者是例如OAuth 1 有点反对，因为整个请求都已签名，不能简单地从早期泄露的请求中获取几个 auth 标头并将它们放在新的伪造请求上。应该检查 Nonce 和时间戳字段以避免逐字重播先前的请求。 （所有这些都被丢弃在 OAuth 2 中，不管它值多少钱……甚至 OAuth 1 在实践中也有一些 notable loopholes ……）
因此，在实践中应谨慎使用代理或 JWT 身份验证处理程序。假设围绕您的 CouchDB 和身份验证源绘制了各种各样的“防火墙”，那么正如@Flimzy 的回答提到的那样，防止意外的标头从该边界外向内 - 以及防止真正的标头向外泄漏 - 应该减轻大多数潜在的滥用.
【讨论】：