6

围绕 REST 和安全性主题有许多关于 SO 的优秀问题（和答案）。许多人说“纯粹主义者不会喜欢这个，但是等等等等”......然后其他人说“你不应该那样做，因为等等等等”。

但是我还没有看到“纯粹主义者”针对以下情况提出的解决方案。所以我的问题是 - 以下场景的“纯 RESTful 解决方案”是什么？

简单的场景...

想象一下建立一个数据库/网站，让用户管理他们最喜欢的食谱。该网站公开了一个 RESTful API，以便用户可以从他们想要编写的自定义程序（利用此 API）中查询和操作他们的列表。

因此，用户“A”有 3 个最喜欢的食谱，ID 分别为“1”、“2”和“3”。

用户“B”有 2 个最喜欢的食谱，ID 为“4”和“5”。

我们需要确保如果用户 A 向其发送DELETE命令/Recipes/4，他将得到Forbidden (403)响应。

我平时会做什么...

我通常会做的是让他们首先调用一种身份验证方法，然后向他们发送某种有效期为 30 分钟左右的身份验证令牌。通常，此令牌将通过 cookie 传递。

什么是纯溶液？

纯 REST 解决方案是让他们将其作为查询字符串中的变量传递吗？饼干是魔鬼吗？令牌是否应该用作 URL 的一部分（而不是查询字符串参数）？还有什么可以清楚地回答这个问题吗？

4

3 回答 3

4

在授权标头中传递令牌。这就是它的设计目的。见http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-12.html

于 2012-06-02T12:26:55.723 回答
1

将身份验证令牌视为资源。

您通过 GETting 身份验证令牌进行身份验证，其参数为凭据（例如，通过 https 的基本身份验证）。

通过删除登录时获得的身份验证令牌资源来注销。

于 2012-06-02T03:09:05.330 回答
0

一个简单的无状态且无 cookie 的解决方案是为您的每个用户提供一个相同的令牌。

有一些方法可以生成这些令牌，以便它们足够稀疏以应对安全问题。

例如https://www.grc.com/passwords.htm

假设您有用户 A 和用户 B。您为用户 A 生成令牌 X，为用户 B 生成令牌 Y。

所以用户A会使用类似的东西/X/Recipes/1

用户 B 将使用类似的东西/Y/Recipes/4

这是安全的，因为用户 A 是唯一知道他的令牌的人，正如我之前提到的，生成令牌的方式可以确保其他人“不可能”猜到该令牌。

因此，如果其他人（例如用户 B）在 url 中使用其他令牌，例如/Z/Recipes/1，您应该能够识别并返回相应的错误消息。

您可以让用户在 url 中传递令牌，就像我在上面展示的那样，或者将它作为 Autherticantion 消息嵌入到 HTTP 请求中。

于 2012-06-02T02:48:52.293 回答