CORS issue with "webpack-dev-server": "^1.14.1"

[Soolan]

Hi everyone, I'm using:

    "webpack": "^1.12.9",
    "webpack-dev-server": "^1.14.1",
    "webpack-merge": "^0.8.4"

and I get the following error when I try to hit googleapis:

XMLHttpRequest cannot load http://ajax.googleapis.com/ajax/services/feed/load?v=1.0&num=8&q=http://rss.cnn.com/rss/edition_entertainment.rss?output=rss. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.

I have added following settings in webpack.config.js:

// Webpack Config
var webpackConfig = {
  headers: {
    "Access-Control-Allow-Origin": "http://localhost:3000",
    "Access-Control-Allow-Credentials": "true",
    "Access-Control-Allow-Headers": "Content-Type, Authorization, x-id, Content-Length, X-Requested-With",
    "Access-Control-Allow-Methods": "GET, POST, PUT, DELETE, OPTIONS"
}

... but I still getting the same error. Can anyone give me some advice please? Thank you for your time.

[poonam6785]

I am facing the same CORS issue when i try to fetch data from "http://en.wikipedia.org/w/api.php?format=json&action=query&generator=random&grnnamespace=0&grnlimit=10". I am using "dependencies": { "react": "^15.2.1", "react-dom": "^15.2.1", "webpack": "^1.13.1", "webpack-dev-server": "^1.14.1" },

Its working in chrome if i enable CORS extension in chrome. Thanks

[SpaceK33z]

The headers object should be in the devServer object in your webpack config. See also this example.

[Soolan]

Thanks @SpaceK33z , I edit the file as follow:

  devServer: {
    historyApiFallback: true,
    watchOptions: { aggregateTimeout: 300, poll: 1000 },
    headers: {
      "Access-Control-Allow-Origin": "*",
      "Access-Control-Allow-Methods": "GET, POST, PUT, DELETE, PATCH, OPTIONS",
      "Access-Control-Allow-Headers": "X-Requested-With, content-type, Authorization"
    }
  },

Still no luck. Your advice is much appreciated.

[SpaceK33z]

@Soolan, I did a quick test using fetch, and this works:

fetch('http://ajax.googleapis.com/ajax/services/feed/load?v=1.0&num=8&q=http://rss.cnn.com/rss/edition_entertainment.rss?output=rss', {
    method: 'get',
    mode: 'no-cors',
}).then(() => {
    console.log('Works!');
});

I don't know what library you're using for XHR, but most libraries have support for something like the above (no-cors).

[Soolan]

@SpaceK33z, thank you for your time. I'm using Angular2 Http module and what I'm trying to accomplish is fetching the latest trends from this URL: http://hawttrends.appspot.com/api/terms/

Since CORS didn't work for me I tried JSONP (i.e. http://hawttrends.appspot.com/api/terms/?callback=JSONP_CALLBACK)

But I got another issue regarding response which I asked for help here: http://stackoverflow.com/questions/38810930/angular2-unexpected-token

[SpaceK33z]

Okay, JSONP is also a solution for this problem. Could you close this issue then? This is not a bug in webpack-dev-server ;).

[CodePlayer7]

@SpaceK33z your test do works but the json data cannot be fetched.Only get response likes body:(...),bodyUsed:false,headers:Headers,ok:false,status:0,statusText:"",type:"opaque",url:""

[emeentag]

I experienced the same like @CallMeXYZ. Also adding no-cors mode is not a solution, it could be a solution but for the production, it is not acceptable. Anyway when i add no-cors mode i am getting an error like Response {type: "opaque", url: "", redirected: false, status: 0, ok: false…}

[andrerpena]

Today I updated webpack-dev-server from 2.4.1 to 2.4.3 and suddenly HMR stopped working until I added this to my webpack config file:

devServer: {
        headers: {
            'Access-Control-Allow-Origin': '*'
        }
    }

[karolyi]

@andrerpena interestingly, even if I add those headers in the config with today's 2.4.3, they are absent in the HTTP headers. My dev site is broken.

Investigating the issue.

[karolyi]

I found the problem, but I'm not sure it's my fault. Webpack is still overly complicated, configurations traveling here and there.

I use Gulp and Webpack, and so I have a gulpfile.js. Whereas when I put the headers into the webpack config file (from where gulp takes the config in a compiler and passes to WebpackDevServer) doesn't work, when I put the headers into gulpfile.js passing as 'extra options', that works.

So here's my current gulp task with which adds the headers to the wrong config in my opinion:

gulp.task('webpack-dev-server', ['clean'], () => {
  const config = require('./frontend/webpack/config.dev-server')

  const compiler = webpack(config)
  const server = new WebpackDevServer(compiler, {
    hot: true,
    inline: true,
    historyApiFallback: true,
    contentBase: path.join(__dirname, 'frontend', 'src'),
    publicPath: '/static/assets/',
    stats: {
      colors: true,
    },
    headers: {
      'Access-Control-Allow-Origin': '*',
    },
  })
  server.listen(3000, '0.0.0.0', (err) => {
    if (err) throw new gutil.PluginError('webpack-dev-server', err)
    // Server listening
    gutil.log('[webpack-dev-server]', 'http://localhost:3000/')
  })
})

This extra headers config should go into the actual webpack configuration (./frontend/webpack/config.dev-server in my case), but it doesn't work there.

Leaving this here as information for future reference, and for people who bump into the same problem.

I'm not sure as to what changed that caused CORS to start being enforced, because I reverted webpack-dev-server to 2.4.2, and it still doesn't work there, the CORS headers aren't there either. I used it yesterday, and it worked, but it doesn't today. Might be it's a chrome update, I don't know.

[cchamberlain]

@karolyi that is the documented way that it works. When using the WebpackDevServer from node API it doesn't get devServer configuration from the compiler per:

If you want to specify it in the config simply:

  const config = require('./frontend/webpack/config.dev-server')

  const compiler = webpack(config)
  const server = new WebpackDevServer(compiler, config.devServer)

[michaelBenin]

Any reason why the default isn't * ?

Releated: https://github.com/gaearon/react-hot-loader/issues/56

[olehmelnyk]

well, Google Chome can be started with two flags/params: --user-data-dir="C:/Chrome dev session" --disable-web-security this will start the browser as a completely new user profile (which is good for dev) and with CORS enabled...

webpack-dev-server has the option to automatically open HTML in the browser once compilation is done, like

devServer: {
    open: true
}

so it would be awesome if we could open it in chrome browser with --user-data-dir and --disable-web-security flags - any idea how to make it work?

[shellscape]

@olehmelnyk solid info. webpack-dev-server uses the opn module, and looking at that it does appear they provide for sending args to the browser command.

https://github.com/webpack/webpack-dev-server/blob/master/bin/webpack-dev-server.js#L463-L470

So in addition to checking if it's a string, we'd need to see if JSON can parse it, and if so, check to see it's got an app property; use the object if so, otherwise fall back to string. And we'd also have to check for an Object in the event that was specified in the devOptions in webpack.config.js. Whew.

I think might be a classic case of wds trying to do too much. What a better route might be, would be to petition the opn project to check for a config file that specified how to open certain things; in this case URLs. An .opnrc for example.

[olehmelnyk]

yay! looks like I've found what I was looking for: npm i -D webpack-browser-plugin then

const path = require('path');
const browserPlugin = require('webpack-browser-plugin');
const chromeUserDataDir = 'your/path/here';

...

plugins: [
     new browserPlugin({
            openOptions: {
                app: [
                    'chrome',
                    //'--incognito',
                    '--disable-web-security', // to enable CORS
                    '--user-data-dir=' + path.resolve(chromeUserDataDir) // to let Chrome create and store here developers plugins, settings, etc.
                ]
            }
        })
]

and now you can work with CORS, and have a dedicated Google Chrome user profile that will include developer plugins and settings and will not overlap with browser settings/plugins for private use

[shellscape]

@olehmelnyk awesome that you found a solution. though it does make me just a tiny bit sad that it requires more webpack config. still, it works!

[thunderkid]

I've found a solution to my ongoing CORS errors - switch to webpack-plugin-serve.

FWIW, I'd been using webpack-dev-server since webpack 3 and had never been able to get rid of these CORS/sockjs-node errors in the console. I've tried everything listed on this and multiple similar threads - adding Access-Control-Allow-Origin, changing from localhost to 0.0.0.0, changing ports, running chrome without web-security, etc etc. None of these worked for me. I considered switching from webpack-dev-server to webpack-serve, but first one of these stated on its webpage that it was deprecated, then the other one did, then back to the first one. I forget the precise order in which these deprecation notices occurred but they made me nervous about the projects' status.

Then around the end of 2018 I came across webpack-plugin-serve. It took about an hour of configuration to switch over, and I now get zero console errors. I also slightly prefer its ui (it has a browser overlay of build progress.) So I'd recommend it.

[karolyi]

Quick update: the access control headers are now replaced to disableHostCheck: true in the config due to #1604.

[dyardyGIT]

@thunderkid can you share your webpack.config.js ?

[thunderkid]

@dyardyGIT You mean my old one for webpack-dev-server or the new one for webpack-plugin-serve?

[dyardyGIT]

@thunderkid it would be nice to see both

I also switched over to webpack-plugin-serve and many of my issues have been resolved (authentication, cors, and I can how browse to site via http://localhost which is on IIS)...is this too good to be true?

Here is my package.json that I am using

{ "name": "odot.web", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "start": "wp --config webpack.config.js", "builddev": "webpack --config webpack.config.js", "build": "cross-env NODE_ENV=production webpack --config webpack.config.js --progress" }, "author": "", "license": "ISC", "dependencies": { "@babel/runtime": "^7.7.2", "vue": "^2.1.10" }, "devDependencies": { "@babel/core": "^7.7.2", "@babel/plugin-transform-runtime": "^7.6.2", "@babel/preset-env": "^7.7.1", "babel-loader": "^8.0.6", "babel-preset-vue": "^2.0.2", "cross-env": "^6.0.3", "css-loader": "^3.2.0", "file-loader": "^4.2.0", "uglifyjs-webpack-plugin": "^2.2.0", "vue-loader": "^15.7.2", "vue-template-compiler": "^2.6.10", "webpack": "^4.41.2", "webpack-cli": "^3.3.10", "webpack-dev-server": "^3.9.0", "webpack-nano": "^0.8.1", "webpack-plugin-serve": "^0.12.1" } }

[andywwright]

The amount of trickery one should get himself into for simply enabling CORS is just ridiculous.