Webpack-dev-server，React，Fetch和Cookies

Today’s fun. I’m using webpack-dev-server to serve up my React application as I develop it. I’m implementing JavaScript Web Tokens, with Refresh Tokens via an httpOnly cookie between domains via a fetch() request. While I receive the httpOnly cookie on my fetch response the cookie does not translate to the Application tab in devtools, which means it will not be automatically passed with my next API request.

今天的乐趣。 我正在使用webpack-dev-server开发我的React应用程序。 我正在实现JavaScript Web令牌，并通过fetch()请求通过域之间的httpOnly cookie使用刷新令牌。 当我在提取响应中收到httpOnly cookie时，该cookie不会转换为devtools中的Application选项卡，这意味着它将不会与下一个API请求一起自动传递。

I spent a while trying to track this down and present my solution (one of many possibilities) in this post.

我花了一段时间试图找出答案，并在这篇文章中介绍了我的解决方案(多种可能性之一)。

The problem is one of trust. If you are serving content from a single domain, there are few issues. However, if your API server is running on http://localhost:3000, and your React application is running via webpack-dev-server on http://localhost:8081 (for instance), then as far as the browser is concerned these are different domains and the security rules kick in. Those rules require more setup and understanding to tell the browser that we really do trust that other domain. And those extra steps STILL may not work because of how webpack-dev-server works.

问题是信任之一。 如果您要从单个域提供内容，则几乎没有问题。 但是，如果您的API服务器在http：// localhost：3000上运行，并且您的React应用程序通过http：// localhost：8081上的webpack-dev-server运行，那么就浏览器而言这些是不同的域，并且会引入安全规则。这些规则需要更多的设置和了解，才能告诉浏览器我们确实信任其他域。 由于webpack-dev-server的工作方式，这些额外的步骤STILL可能不起作用。

If you are using Fetch() to request an API resource, you have to include mode: 'cors' and credentials: 'same-origin'. But even these may not be enough.

如果使用Fetch()请求API资源，则必须包括mode: 'cors'和credentials: 'same-origin' 。 但是，即使这些可能还不够。

The “easy” fix is to move your API requests behind a proxy that then appears to be originating from your main domain. For example navigating to http://localhost:8081/api/login would result in a call to http://localhost:3000/api/login without the browser knowing. This is relatively easy to set up in Nginx/Apache:

“简单”的解决方法是将您的API请求移到一个似乎来自您的主域的代理之后。 例如，导航到http://localhost:8081/api/login将导致在浏览器未知的情况下调用http://localhost: 3000 /api/login 。 在Nginx / Apache中设置起来相对容易：

// nginx
location '/api' {
  proxy_set_header   X-Forwarded-For $remote_addr;
  proxy_set_header   Host $http_host;
  proxy_pass         http://localhost:3000;
}

But when we are developing we may only be using webpack-dev-server.

但是，当我们进行开发时，我们可能仅使用webpack-dev-server。

Webpack-dev-server can do proxies too. It just takes a little setup.

Webpack-dev-server也可以做代理。 只需进行一些设置。

In your webpack.config.js file you can setup a proxy with something like this:

在您的webpack.config.js文件中，您可以使用以下内容设置代理：

module.exports = merge(common, {
  ...
  devServer: {
    contentBase: './dist',
    // the historyAPIFallback allows react-router to work
    historyApiFallback: true,
    proxy: {
      // when a requst to /api is done, we want to apply a proxy
      '/api': {
        changeOrigin: true,
        cookieDomainRewrite: 'localhost',
        target: 'http://localhost:3000',
        onProxyReq: (proxyReq) => {
        if (proxyReq.getHeader('origin')) {
          proxyReq.setHeader('origin', 'http://localhost:3000')
        }
    },
  },
  ...// derived from code found at https://sdk.gooddata.com/gooddata-ui/docs/4.1.1/ht_configure_webpack_proxy.html

Now when you restart your dev server you can make requests to /api and they will get passed through to your API server. As far as the browser is concerned you have requested a resource from the same domain so those pesky security rules do not apply.

现在，当您重新启动开发服务器时，您可以向/api发出请求，它们将被传递到您的API服务器。 就浏览器而言，您已请求来自同一域的资源，因此这些讨厌的安全规则不适用。

Most importantly, the httpOnly cookies are properly set on the Application tab in your browser’s devtools. (You still may need to mess with headers and/or mode/credential settings for fetch().) Which means that the *next* request you make will pass along that cookie as well. Viola — we can use a JWT token without storing it in the browser and exposing it to malicious JS attacks.

最重要的是，已在浏览器的devtools的“应用程序”选项卡上正确设置了httpOnly cookie。 (您可能仍需要弄乱fetch()的标头和/或模式/凭据设置。)这意味着您发出的* next *请求也将传递该cookie。 Viola-我们可以使用JWT令牌，而无需将其存储在浏览器中并将其暴露给恶意JS攻击。

As an added bonus, our React application no longer has to keep track of where the API server is. All API resources can just point to /api and the underlying server takes care of the correct proxy call.

另外，我们的React应用程序不再需要跟踪API服务器的位置。 所有API资源都可以指向/api ，并且底层服务器负责正确的代理调用。

The *right* answer in the long run is to get it correct for the production environment. That normally means Nginx, Apache, IIS, or another common web server. As long as those servers can configure a directory proxy this is easy.

从长远来看，“正确”的答案是使它适合生产环境。 这通常意味着Nginx，Apache，IIS或其他常见的Web服务器。 只要那些服务器可以配置目录代理，这很容易。

Even if this is not a permanent solution it allows us to continue developing the rest of our application.

即使这不是一个永久性的解决方案，它也允许我们继续开发其余的应用程序。

翻译自: https://medium.com/javascript-in-plain-english/webpack-dev-server-react-fetch-and-cookies-2d4e89840ea2