0

一点背景：我们目前正在尝试在几个供应商之间指定一个 HTTP API，以便不同的产品可以轻松地互操作。我们还没有编写任何“服务器”软件，也没有编写任何客户端，而只是布置了 API 的基础知识，以便每一方都可以开始原型设计，然后我们可以对其进行改进。因此，此 API 的典型用例将由给定应用程序内的（薄）HTTP 层使用，而不是在浏览器内使用。

如果没有会话状态，通信就没有真正意义，所以我们正在研究如何典型地跟踪会话。

问题是，我们希望尽可能简单地实现 API，同时尽可能减少任何使用的 HTTP 库的负担。

有人提出基本上通过“URL重写”来管理会话，但更明确一点：

  • POST .../service/session{ ... }
  • => 回复201 Created和会话 URL 位置.../service/session/{session-uuid}
  • 后续请求使用.../service/session/{session-uuid}/whatever
  • 结束客户端的会话DELETE .../service/session/{session-uuid}

环顾网络，最初的搜索表明这有点不典型。

这是一种有效的方法吗？具体的缺点或优点？

我们确定的优点：（请酌情揭穿）

  • 实施简单，无需 cookie 或标头跟踪等
  • 与客户端身份验证机制正交 - 如果身份验证合适，我们可以轻松地将 URL 传递给可以继续使用会话的第二个应用程序（在我们的案例中是有效的用例）
  • 应该是安全的，因为我们专门为此使用 http 。

由于提到了 PHPSESSID，我偶然发现了另一个问题，其中提到“URL 中的会话”方法可能更容易受到会话固定攻击。

但是，请参阅上面的第二个项目符号：我们计划实现〜指定身份验证/授权与此会话概念正交，因此传递“会话” url 甚至可能是一个功能，因此我们认为让会话出现在网址。

4

0 回答 0