我有一个带有组合键的多租户数据库
clientId - docId
路由看起来像这样
/api/controller/clientId/docId
对于身份验证，我使用“全局”用户名，例如电子邮件 + 密码，通过 https 在每个请求的 http 标头中发送。用户名显式映射到客户端并可在后端使用。
怎样做才能既休息又安全呢？
- 像上面的路由，只需验证根据用户名的 clientId 是否与路由中的相同
or
-
更改路由如下，并在保存记录之前从数据库获取 clientId？
/api/controller/docId
这可能是一个显而易见的问题，但我担心潜在的安全问题。或者选择较短的路线是理所当然的吗？
Thanks!
I think /api/controller/docId可能是最好的主意，或者使用单个代理键来表示 ClientId 和 docId （我的偏好）。
除非您需要允许客户端查看其他客户端资源，否则我会将其隐藏在 URI 方案中，最坏的情况是，它最多可以被视为信息泄漏，但它是多余的，因为您已经对客户端进行了身份验证并知道他们是谁。这也是一项开销，即您仍然必须检查 url 中的客户端 ID 是否映射到请求的用户名和密码，因此您无论如何都需要在每个请求上检索客户端 ID。
如果您了解其他多租户环境的工作原理，例如您可以看到销售人员必须通过安全机制推断客户端，或者很幸运为每个对象/资源拥有唯一的 ID。
我见过的一种方法是将客户端标识符（通常是某种代理键，避免暴露其他用户的数据库 ID！）放在 URL 的根部，例如/api/{clientId}/controller/docId.在多租户环境中，每个资源可能/根据定义对于该客户端来说是唯一的。
有时采用这种方法的原因是，每个客户拥有唯一的 url 有助于缓存... /api/{clientId}/controller/docId 或 /api/controller/{clientId}/docId
关于基本身份验证的简要说明
您的方法没有任何问题，但请考虑...您可以在验证密码和用户名的同时检索客户端 ID，并将其添加为 IPrinciple 上的声明。至少可以在代码中使用它，而无需进一步的数据库查找来找到它（在该请求的生命周期内）。
更进一步...考虑一个两步身份验证机制，其中颁发令牌（遵循正确的用户名和密码），并使用令牌中实际的客户端 ID 作为声明。这样，使用令牌的后续请求意味着您不需要为每个请求回调数据库来验证和检索信息。查看 OAuth 不记名令牌http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html（一定要签名）或其他一些方法......
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
