Open SachaG opened 4 years ago
Are you up to date on devel? Will check but I indeed forgot same origin scenario in the first implementation. I think it's fixed in a recent commit.
You should have this:
const corsOptions =
corsWhitelist && corsWhitelist.length
? {
origin: function(origin, callback) {
if (!origin) callback(null, true); // same origin
if (corsWhitelist.indexOf(origin) !== -1) {
callback(null, true);
} else {
callback(new Error('Not allowed by CORS'));
}
},
}
: process.env.NODE_ENV === 'development';
The case "!origin" correspond to same-origin requests, so the app itself.
I think I've reproduced that in Vulcan Meteor Next Transition, see sample settings: https://github.com/VulcanJS/Vulcan-Starter/blob/33a23bc3c22b6d5d73071d0b7f1c863f01149cc5/sample_settings.json To be investigated by trying to query the Meteor app from itself, eg via graphql playground.
I tried specifying the
apolloServer.corsWhitelist
setting to enable Apollo Studio's Explorer to work. This worked well enough, but GraphQL requests coming from the app itself then started to fail until I explicitly added it.I think even with the whitelist option specified, we should probably make an exception so that requests coming from the app always work?