情况
我的队友决定使用Cookie来跟踪会话。因此,成功登录后,将在加载SPA的Web浏览器中设置仅限http的cookie。
问题
如果我们将SPA放在服务器的public_html目录中,一切运行良好。但是,这会使SPA成为API代码的一部分。这打破了我们的构建过程,因为每次升级到SPA现在都需要升级API。
如果我们在一个仅提供静态SPA文件的单独网络服务器中托管SPA,我会遇到CORS问题。由于SPA来自与其尝试访问的API不同的来源,因此浏览器会阻止ajax调用。为了解决这个问题,我们必须在服务器端适当地设置Access-Control-Allow-Origin
。我也明白需要设置Access-Control-Allow-Credentials:true
,以指示浏览器设置/发送cookie。
可能的解决方案
我们创建了一个构建过程,每次SPA升级时都会对服务器的public_html目录执行git-pull。我试图避免这种情况,以使客户端和服务器升级分开。
我们创建一种代理类型的情况,其中服务器不存储SPA文件,但是从托管SPA文件的另一台服务器按需收集它们。在这种情况下,Web浏览器将看到来自同一来源的SPA文件和后续的ajax调用。
我们对服务器进行编码,以便在其响应中设置Access-Control-Allow-Origin:*
。首先,这太开放,看起来不安全。 它真的不安全,还是只是我的看法?此外,由于我们设置了Access-Control-Allow-Credentials:true
,因此Chrome会抱怨Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.
。为了解决这个问题,我们必须在Access-Control-Allow-Origin
中放置确切的起源(可能使用正则表达式)。这可能严重限制我们将SPA分发给未知域中的用户。
对于服务器API设计器,基于Cookie的身份验证是推荐的方式来处理SPA的身份验证吗? OAuth2.0 and JWT based Authentication似乎表明基于Cookie的身份验证不适合SPA。任何利弊?
请评论上述选项,或建议您使用过的其他选项。提前谢谢。
答案 0 :(得分:3)
我认为问题在于你的术语令人困惑。 API不是server
,它的应用程序位于也可以是server
的计算机上。如果您创建NodeJS API,我建议您使用Nginx服务器作为反向代理。假设您希望Nginx服务器,API和SPA文件都在同一台机器上,您可以将API部署到目录,将SPA部署到另一个目录,并让Nginx相应地路由请求。
所以我相信解决方案2还有很长的路要走。从那里,您可以通过增加实例数量(如果使用AWS)轻松扩展,并对它们进行负载平衡或将API分离到自己的应用程序服务器中。
至于身份验证。对于SPA或API请求,我一直倾向于使用Header Authorization和cookie访问令牌。尽管您可以通过本地存储保存访问令牌,但每个请求都是自包含且不需要在浏览器上保留持久字符串的想法对我来说更有吸引力。
答案 1 :(得分:3)
我会选择解决方案2或3.
2:您可以在同一台服务器上设置(网页和API)(或使用反向代理),这样从外部角度来看,它们共享相同的来源。
3:对于API,相同的原始策略变得不那么重要了。该API将由不属于您的Web应用程序的客户端使用,不是吗? 我不会在设置更宽松的允许原始标题时看到任何问题。更宽松的是,我不是指通配符,只需添加网页的来源即可。你为什么要通配符呢?