避免在单页应用程序中使用CORS，如何以及为什么？

了解如何通过使用前端开发服务器中的代理配置来避免CORS。

在过去的十年中，单页应用程序已成为构建Web应用程序的标准技术。如今，诸如Angular，Vue之类的框架以及诸如React之类的库主导着前端开发，为这些应用程序提供了基础平台。好消息是，它可以从一个域中为前台和后台API提供服务。但在某些情况下，我们会从不同的子域中为前台(如web.myapp.com)和后台(如api.myapp.com)提供服务。有时，我们只允许对开发环境的后端API进行跨域访问。

跨域资源共享（CORS）是在Web浏览器中实现的一种机制，用于允许或拒绝来自其他域的请求到Web应用程序。通过CORS，Web浏览器和Web服务器就标准协议达成一致，以了解是否允许访问资源。因此请记住，从后端执行CORS并不意味着Bots或任何其他机制都无法访问您的服务器资源。

你需要CORS吗？

但是，我们是否需要为你的Web应用提供CORS？我想说的是，大多数情况下，你不需要担心CORS，因为你的网络应用是由一个域提供的。然而，可能会有一些特殊的特性，比如允许在主Web应用程序域之外嵌入页面(例如，表单、视频)，你可以考虑在后端启用CORS。不过，你仍然可以启用限定范围到该特定特性的CORS。

CORS的问题

除安全性外，CORS最明显的问题是对Web应用程序性能的影响。当你的前端向不同的域或子域发送一个HTTP请求时，浏览器会发送一个额外的HTTP，称为preflight（预检）请求，看服务器是否接受来自发件人域的消息。

因此，对于每个由前端触发的HTTP请求，浏览器需要发送两个HTTP请求，从而增加了总体响应时间。在大多数情况下，添加的延迟在Web应用程序中是可见的，并且会对用户体验产生负面影响。

单页应用程序中的CORS

当涉及到单页面应用程序时，CORS的使用就显得更为明显。Web浏览器，如果web应用只使用HTTP头（Accept、Accept-Language、DPR、Downlink、Save-Data、Viewport-Width、Width、Content-Language、Content-Type（除了值application/x-www-form-urlencoded、multipart/form-data、text/plan））和HTTP方法（GET、HEAD、POST）来进行后端API调用，那么Web浏览器就不会考虑预检请求。在你的单页面应用程序中，你可能需要这些HTTP头和HTTP方法以外的内容。

在这些应用中，我们在前端定义后端API的URL作为服务器操作的变量。此外，我们甚至可能会在后端API中授予CORS来进行开发，因为前台和后端API的开发服务器可能在两个不同的端口上运行。开发环境可能还会影响生产环境中的设置，你可能会在其中将前端API和后端API部署在不同的子域中。

但是我们需要沿着这个方向走吗？让我们看看在开发和生产环境中避免CORS的方法。

在开发环境中避免CORS

今天，我们选择用于前端开发的大多数开发服务器都使用NodeJS。这些Node服务器中的大多数都支持代理配置。此外，Angular，React和Vue附带了Webpack开发服务器，该服务器内置了对代理配置的支持。

那么这个代理配置到底是做什么的呢？

假设你的前端应用程序在 http://localhost:4200 中运行，而后端API在 http://localhost:3000/api/ <resource> 中运行。我们的前台需要存储后端API的URL和端口，以便在本地运行应用程序。为了支持这一点，你还需要在你的后端API中启用CORS，允许从运行在 http://locahost:4200 的前端服务器上访问。

通过在前端开发服务器中使用代理配置，我们可以避免上述所有麻烦。使用代理时，只需在前端应用程序中存储相对路径（/api）。在本地运行应用程序时，你的前端将尝试使用相同的域和端口（http://localhost:4200 /api/<resource>）访问后端API，浏览器无需担心CORS。

在此阶段，代理会尽力而为。在代理配置内部，你可以定义将在前端开发服务器上针对路径 /api 的所有请求转发到 http://localhost:3000。

由于开发服务器是与后端API通信的中间人，因此可以安全地避免CORS。下面的示例显示了如何在Webpack开发服务器中添加代理配置。

module.exports = {
  //...
  devServer: {
    proxy: {
      '/api': 'http://localhost:3000'
    }
  }
};

在生产环境中避免CORS

在生产环境中，除非你的前端和后端API在同一Web服务器中运行，否则你需要在它们的前面设置网关或代理以从单个域提供服务。在某些情况下，如果负载均衡器能够基于HTTP路径路由到不同的端点，那么它就足够了。

与dev Server代理类似，网关，代理或负载均衡器根据我们提供的配置来进行路由，并与请求中接收到的HTTP路径匹配。下面的列表包含了一些常用的网关、代理和负载均衡器，支持基于URL路径的路由，供大家参考。

• NGINX
• Traefik
• AWS CloudFront
• AWS Application Load Balancer
• Azure Application Gateway

此外，通过只允许同源访问来加强CORS的后端API是非常重要的。

概括

总体而言，我希望你了解CORS的性能含义以及在单页应用程序中避免使用它的好处。除了性能之外，安全性是现代浏览器中建立CORS的最终原因，因此，至关重要的是要了解CORS在安全性方面的工作原理。但是，你应该能够找到有关CORS和安全性的足够或更多的内容，这不是本文的重点。我在这里的重点是避免在单页应用程序中首先使用CORS。

既然我已经触及到了使用代理来避免CORS，你可能会想知道，当前端和后端API在不同的服务上运行时，设置一个代理有多难？然而，设置代理比你想象的要简单。例如，为Angular、React或Vue设置一个开发服务器代理，只需在Webpack配置文件中添加几行内容来代理你的请求到后端API，从而避免CORS。这同样适用于生产环境，因为实现基于URL路径的路由有很好的方法。

但是，你必须为后端API建立适当的路径转换，以避免每次添加新端点时都需要更新代理配置。例如，如果你使用一个基础路径（例如，\api\），那么写一个简单的规则，将所有具有该基础路径的请求路由到后端API，并将其他HTTP路径的请求回落到前端资产就比较容易。

最后，我想再次强调一下，如果你不需要使用CORS，请在开发和生产环境中仅对后端API启用相同来源的访问权限。根据我的经验，它将节省大量时间，避免了很多陷阱。

---

来源：https://blog.bitsrc.io，翻译：前端外文精选

本文首发于微信公众号《前端外文精选》，关注即送大礼包，准能为你节省不少钱！