2

我有一个分成两部分的网络应用程序。

  1. 一个 JavaScript 前端。(myfrontend.com)
  2. API 后端(node.js)。(mybackend.com)

这两个部分托管在不同的域上,我需要这样,因为最终我将为同一个后端(即移动 Web 应用程序等)构建更多前端

我现在验证的方式:

  1. 用户从 myfrontend.com 登录,凭据被发送(ajax)到 mybackend.com ,在那里它们与数据库进行检查。如果他们不检查,则不会发生任何事情,并且 mybackend.com 会以错误代码进行响应。

  2. 如果他们确实签出,我使用 express.js 的 cookie-sessions 并且 mybackend.com 使用 cookie (for the mybackend.com domain) 响应。服务器将从数据库检索到的用户 ID 链接到会话。

  3. 从那时起,对 mybackend.com 的所有请求都包含 cookie,后端使用 cookie 查找会话,并使用会话中的 user-id 信息正确响应。

最初我遇到了一堆 CORS 问题,但是在设置了所有正确的标题(如 withCredentials 等)之后,在每个浏览器中一切都很好。

我认为这是一个非常优雅的解决方案,因为所有用户信息都被严格隔离在后端,前端从不接收任何用户数据,只是一个短暂的 cookie。

所以我有两个问题:

  1. 这是做这种事情的正确方法吗?OAuth 的实现方式与此有何不同,是否有优势?

  2. 如果我在 chrome 中关闭第三方 cookie,这将停止工作。但是,在 Safari 中关闭第三方 cookie 仍然可以正常工作。这是怎么回事?当您将 ajax 发送到“mybackend.com”被视为第三方 cookie 时,为什么会为“mybackend.com”获取 cookie?如果我使用 iframe 或其他东西可以吗?我应该担心这个吗?

4

1 回答 1

1
  1. 是的,这是一个很好的使用模式。我在http://hackhall.com ( https://github.com/azat-co/hackhall )中使用了相同的方法。OAuth 更多的是用于三向身份验证:消费者、服务提供者和您的应用程序。OAuth 1.0 需要“oauth dance”来获取时间敏感的访问令牌。OAuth 2.0 更容易,因为在消费者第一次获得令牌后,它们可以交换为充当密码的永久持有者。OAuth Echo 用于委托调用/请求。

  2. 与浏览器和/或 cookie 标头的严格性有关吗?

于 2013-09-01T00:10:20.280 回答