Cookie Auth:从localhost请求实时服务

时间:2017-08-20 23:10:43

标签: javascript authentication localhost frontend netflix-zuul

在我正在开发的平台上,我们在Express.js服务器上运行React前端,在localhost上开发时,我们在我们的staging环境(来自localhost)中调用我们的API。它自己的云域。

我们最近在登台环境中的API网关级别(Zuul)设置了Cookie身份验证。由于我们在开发时直接在localhost上运行我们的React应用程序(没有Zuul网关),该应用程序正在调用登台API而不首先进行身份验证(没有身份验证cookie)。这导致我们的localhost设置在对API的所有请求上失败。我尝试了一些将令牌注入浏览器或强制它们在应用程序中设置的解决方案,但是仍然存在x-origin请求的问题(从localhost到staging)。

我开始质疑我们的前端开发设置。由于我们在多个实时环境中设置API的方式,我们很难在本地运行API并连接到实时数据库和中间层服务。所以,我更愿意找到一种方法来将这些请求从localhost发送到暂存工作。

我们有服务器端和客户端请求(ajax)需要访问这些服务,我们正在使用Axios来处理请求。我想通过设置/etc/hosts和代理请求可能有办法实现这一点,但我不确定如何做到这一点。

在具有身份验证的微服务环境中开发时,是否有推荐的方法来解决前端应用程序的本地开发设置?在本地开发时,我们是否应该尝试使用实时API?建议表示赞赏。

1 个答案:

答案 0 :(得分:0)

我想到了一个问题和一条建议。

  1. 您可能遇到了跨域资源共享(CORS)问题。基本上,如果浏览器阻止您访问其他域以避免恶意攻击,除非该服务明确允许此操作。例如,如果您的前端应用程序在www.mydomain.com/app中运行且您的api位于www.mydomain.com/api,则不会出现问题。但是,如果您的前端应用程序在www.mydomain.com上运行且您的api在api.mydomain.com上,那么您的api必须明确允许来自www.mydomain.com的请求。对于localhost也是如此,因为它被视为不同的域。配置取决于您拥有的服务器类型,您应该在其文档中查找。

  2. 现在大多数API遵循Rest架构,这使得这些API无状态。这意味着API并不关心任何客户的状态。不幸的是,这不是cookie的情况,因为它们必须保留在服务器端和客户端,因此它们是有状态的。如果您想改进API的设计,我建议您使用令牌,更具体地说是JSON Web令牌(JWT)。 JWT是无状态的,也可以更便宜地处理服务器,因为没有必要跟踪它。它基于最初使用编码算法生成的数字签名工作,并且使用解码算法完成验证。 Here一个很好的完整比较。