我有一个带有复合键的 Multi-Tenancy 数据库
clientId - docId
路由看起来像这样
/api/controller/clientId/docId
对于身份验证，我使用“全局”用户名，例如电子邮件 + 密码，通过 https 在每个请求的 http header 中发送。用户名明确映射到客户端并且在后端可用。
有什么方法可以在休息时正确地做到这一点并获得最佳安全性？
要么
/api/controller/docId 这可能是一个显而易见的问题，但我担心潜在的安全问题。或者使用较短的路由只是一个明智的选择？
谢谢!
最佳答案
我认为 /api/controller/docId 可能是最好的主意，或者使用单个代理键来表示 ClientId 和 docId (我的偏好)。
除非您需要允许客户端查看其他客户端资源，否则我会将其隐藏在 URI 方案中，在最坏的情况下，它最多可以被视为信息泄漏，因为您已经对客户端进行了身份验证并知道他们是谁。这也是一个开销，即您仍然必须检查 url 中的客户端 ID 是否映射到请求的用户名和密码，因此无论如何您都需要检索每个请求的客户端 ID。
如果您查看了其他 Multi-Tenancy 环境的工作方式，例如您可以看到销售人员必须通过安全机制推断客户，或者幸运地为每个对象/资源拥有唯一的 ID。
我见过的一种方法是将客户端标识符(通常是某种代理键，避免暴露其他用户的数据库 ID!)放在 URL 的根目录下，例如/api/{clientId}/controller/docId.在 Multi-Tenancy 环境中，每个资源可能/根据定义对该客户端来说都是独一无二的。
这种方法有时给出的一个原因是每个客户都有一个唯一的 url 有助于缓存.../api/{clientId}/controller/docId 或/api/controller/{clientId}/docId
关于基本认证的简要说明
您的方法没有错，但请考虑……您可以在验证密码和用户名的同时检索客户端 ID，并将其添加为 IP 原则的声明。至少可以在代码中使用，无需任何进一步的数据库查找来找到它(在该请求的生命周期内)。
更进一步......考虑一个两步验证机制，其中颁发 token (遵循正确的用户名和密码)，并在 token 中实际使用客户端 ID 作为声明。这样，带有 token 的后续请求意味着您不需要为每个请求回调数据库来验证和检索信息。看看 OAuth 不记名 token http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html(一定要签名)或其他一些方法......
关于带有由客户端分隔的 Multi-Tenancy 数据库的 Rest API，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13761336/