4 回答
假设我正确解释了您的问题,让我尝试为您连接这些点。您发布的链接有一个有效的答案,每个请求都应该使用 HTTP 身份验证。如果您需要许可证的概念来为您的用户维护某种状态,您很可能会将其链接到用户。您有一个(经过验证的)用户名可供使用。您只需要为每个请求调用该控制器并保存其状态。你有你的会议。
任何关键信息都不应信任 Cookie 输入,但对于像安全令牌这样的额外验证非常有用。我认为在您的现场链接中添加一个随机安全令牌字段将是一种宁静的方法。当然,它应该随着“会话”到期。
您可能需要考虑将许可证处理问题向下推到基础架构堆栈上一级。如果你愿意的话,有点像面向方面的编程(AOP)方法。您可以将其推送到 Web 服务器层,而不是在应用程序层处理它。
在不了解您的基础架构的详细信息的情况下,很难给出具体的建议。以 *nix 平台为例,许可证处理逻辑可以作为 Apache HTTP 服务器的一个模块来实现。
这种方法促进了跨基础架构堆栈的关注点分离。它允许每一层都专注于它的意图。应用层根本不需要担心许可问题,允许它严格关注内容,从而保持 URL 的干净和“RESTful”。
如果您的许可是基于并发用户的,那么实现 HTTP 摘要是微不足道的,并且只允许您启用最大数量的并发登录。Digest 提供了传递过期数据的功能,因此您的会话可以超时。
身份验证状态由 http authetnication 持有,其他任何地方都没有,因为它是透明且无处不在的。
也许一种更 RESTful 的许可方式是限制处理请求的速率,而不是限制并发会话的数量。跟踪过去一小时内的请求数量,如果超过客户支付的数量,则提供503 Service Unavailable
响应,以及一些建议用户稍后再试的文本。