【问题标题】:Api First and Single Page ApplicationApi首页和单页应用
【发布时间】:2013-03-27 20:59:29
【问题描述】:

我正在构建一个单页应用程序和一个 REST API 来处理来自客户端和任何可能的第三方客户端的请求。

我的想法是创建三个服务器:

  • A - API,基于 OAuth
  • B - 带有 html/css/js 文件 + 部分/视图的静态文件
  • C - 处理登录的 Web 服务器(节点或 python 或任何东西)

可能第四个处理与 Redis 或其他任何东西的会话。

我希望 SPA 让用户注册和/或登录到服务器 C,给他一个访问令牌并让他直接与 API (A) 对话。

我的问题是处理这个问题的正确机制是什么?

  • 将带有访问令牌的会话 cookie 设置到主应用程序客户端 (SPA),这样只要会话存在,它就可以与 REST API 对话
  • 为了避免创建服务器 C 并在服务器 A 中处理身份验证,(那么第三方服务呢?)
  • 其他的

我的问题有点混乱,请随时向我询问更多详细信息。

【问题讨论】:

  • 我刚才问了一个类似的问题,但没有得到太多反馈:stackoverflow.com/questions/15362639/… - 我建议从简单(r)开始...
  • 是的,我已经看到了这个问题以及更多问题,但不幸的是,这对我来说听起来不够清楚。 “简单(r)”是什么意思?
  • 一开始就将 OAuth 排除在外...也许您可以使用刚刚签名的请求?

标签: security rest web oauth single-page-application


【解决方案1】:

您基本上描述的是“票务”系统,只是您将票称为“令牌”。多年来,这个问题已经用不同的标准化协议以不同的方式处理。麻省理工学院开发的一个非常流行的开放标准是Kerberos。

如果可能,我强烈建议使用现有协议和现有实现。尝试“推出自己的”安全性非常非常困难,并且通常会导致应用程序易受攻击。想想多年来困扰微软的瘟疫,与 *nix 系统相对安全的声誉相比 :-)

我的第一种方法是采用 Kerberos 或其他类似协议。如果您一心想自己动手,那么越简单越好。我会采用类似您的第二个解决方案并废弃服务器 C。让不同的服务器执行身份验证时出错的空间太大。

我知道这不是您所希望的答案,但我希望它有所帮助。

【讨论】:

  • 我不一定要设置票务系统,而是为我的系统处理身份验证的好方法。我刚刚发现了单页应用程序的世界,我想知道如何处理安全性和身份验证。谢谢你的回答顺便说一句:)
猜你喜欢
  • 2020-06-26
  • 2015-05-09
  • 2012-12-10
  • 1970-01-01
  • 2020-06-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-11-24
相关资源
最近更新 更多