clientId - docId
路由看起来像这样
/api/controller/clientId/docId
对于身份验证,我使用“全局”用户名,如电子邮件密码,通过https发送在每个请求的http标头中.用户名明确地映射到客户端,并在后端可用.
有什么办法妥善地休息和最好的安全性？
>如上所述,只需验证根据用户名的clientId与路由中的相同
要么
>更改路由如下,在保存记录之前从数据库获取clientId？
/ API /控制器/的docId
这可能是一个明显的问题,但我担心潜在的安全问题.还是用较短的路由去做一个没有脑子的人？
谢谢！
解决方法
除非您需要允许客户端查看其他客户端资源,否则我将其从URI方案中隐藏起来,最糟糕的是,它可以被视为信息泄漏,因为您已经对客户端进行身份验证,并且知道他们是谁.这也是一个开销,即您仍然必须检查url中的客户端ID映射到请求的用户名和密码,以便您需要在每个请求上检索客户端id.
如果您看看其他多租户环境如何工作,例如销售部队的你可以看到,他们必须通过安全机制来推断客户端,或者对于每个对象/资源都有一个唯一的id来说足够幸运.
我所看到的一种方法是将客户端标识符(通常是某种的替代密钥,避免暴露其他用户的数据库ID)！ / API / {的clientId} /控制器/的docId.在多租赁环境中,每个资源大概/根据该客户端唯一的定义.
有时候给出这种方法的一个原因是每个客户端都有一个唯一的URL帮助缓存… / api / {clientId} / controller / docId或/ api / controller / {clientId} / docId
关于基本认证的简要说明
您的方法没有任何问题,但考虑…您可以检索客户端Id,同时验证密码和用户名,并将其添加为IPrinciple的声明.至少在代码中可以使用它,而没有任何进一步的数据库查找可以找到它(在该请求的生命周期内).
进一步考虑一个两步认证机制,其中发出令牌(遵循正确的用户名和密码),客户端Id实际上在令牌中作为声明.这样,随着令牌的后续请求意味着您不需要为每个请求验证和检索信息都调用db.看看OAuth承载令牌http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html(一定要签名)或其他一些方法…
