CORS breaking with IIS?

[ambroseya]

For my development project, I have to be able to make cross origin requests. I am using react-i18next with this, with a very basic setup.

This works fine on production builds where cross origin is not required. However, running it locally is failing. Without using the i18n.js file that uses i18next-xhr-backend, it works perfectly.

When I am using i18next-xhr-backend:

When I have my local IIS instance set to Access-Control-Allow-Origin set to allow all cross origin request, I get: The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed. Origin 'null' is therefore not allowed access. When I have my local IIS instance set with NO Access-Control-Allow-Origin, I get: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.

Somehow, i18next-xhr-backend is setting the Access-Control-Allow-Origin header as double when it is set, and not adding * when it is not present. I can't figure out why this is happening. In my i18n.js file I attempted to set crossDomain: true and crossDomain: false and neither affected the outcome.

The translations are loading fine either way (!) but the page breaks because I can't make any of my other API calls without the proper Access-Control-Allow-Origin header.

import i18n from 'i18next';
import Backend from 'i18next-xhr-backend';
import LanguageDetector from 'i18next-browser-languagedetector';
import { reactI18nextModule } from 'react-i18next';
import * as types from './environment';

i18n
  .use(Backend)
  .use(LanguageDetector)
  .use(reactI18nextModule)
  .init({
    lng: 'en-US',
    fallbackLng: 'en-US',

    ns: ['translations'],
    defaultNS: 'translations',

    debug: true,

    interpolation: {
      escapeValue: false,
    },

    react: {
      wait: true,
    },
    backend: {
      loadPath: `${types.PROJECT_URL}/locales/{{lng}}/{{ns}}.json`,
      crossDomain: true // this seems to be irrelevant to what is happening
    },
  });

export default i18n;

[jamuhl]

Are you using chrome...? If so has todo with chrome policy not allowing localhost as CORS source: https://williambert.online/2013/06/allow-cors-with-localhost-in-chrome/

[ambroseya]

Well, I am using Chrome, but that's not the issue I'm having -- it works perfectly until I use i18next-xhr-backend to load my translations. If I switch to a different or earlier commit before I add this, I get a perfectly normal response. When I add i18next-xhr-backend to load translations, it's as if this package is doubling my settings -- without this package, my header works perfectly as *. When I am using this package, it somehow adds an asterisk, and turns into {*,*} which is an invalid header. When I remove it from IIS, the package just leaves it missing, instead of continuing to add an asterisk. This renders the package unusable to me as there doesn't seem to be a way to get it to have only one asterisk.

I can look at using that link to build an option to possibly see if I can zero out the headers and replace with the correct value, but Chrome works perfectly fine with my setup without this package in use. So does every other browser -- and the other browsers are failing as well (with less specific error messages as I don't have them set up with as many debugging extensions as I have Chrome setup with.)

[jamuhl]

honestly i got no idea...never run into any issue using a node.js server. As personally i have no microsoft products in use i can't say what IIS does to reply with CORS response headers - just never run into any issue or heard of anything related to using the xhr-backend. Access-Control-Allow-Origin is a response header not a request header.

If you find out what the reason is i would be glad to accept a PR.

[adrai]

Is it possible, that IIS is adding the headers? How are your files served? All static or do you use IIS as a proxy but serving from node.js?

[adrai]

Perhaps this can be helpful: http://nodejs.javascripti.com/cors-in-iis-issue-with-credentials-and-wildcard-in-access-control-allow-origin.html

[adrai]

Can you try to set the withCredentials option to true in the backend options for i18next?

[jamuhl]

Any hotreloading, webpack proxy or similar running while development?

[ambroseya]

As an update, in order to fix this I changed so many things that there's no useful change to be reported, for future users.