CORS issue due to content-type header in preflight request

[eloyra]

Hello there! I hope you are having a great day.

I've found this issue (described in the title) while trying to work with the plugin locally.

I use the following simple configuration:

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  defaultMeta: { service: 'user-service' },
  transports: [],
});

if (process.env.NODE_ENV !== ENVIRONMENTS.PROD) {
  logger.add(
    new winston.transports.Console({
      level: LEVELS.DEBUG,
      format: winston.format.simple(),
    })
  );

  logger.add(
    new SlackHook({
      level: LEVELS.DEBUG,
      webhookUrl: process.env.NEXT_PUBLIC_SLACK_LOGGING_WEBHOOK_URL,
    })
  );
}

export { logger };

And then try to log a simple message:

logger.error('whats going on here');

I would expect to find the error both in the console and in Slack, however Slack's call fails:

Access to XMLHttpRequest at 'https://hooks.slack.com/services/xxx/xxx/xxx' from origin 'http://localhost:3000' has been blocked by CORS policy: Request header field content-type is not allowed by Access-Control-Allow-Headers in preflight response.

Here you can take a look to the request headers as provided by this plugin:

And here the payload being sent:

{
    "unfurl_links": false,
    "unfurl_media": false,
    "mrkdwn": false,
    "text": "error: whats going on here"
}

Do you know how to fix this? Can I help in any way?

[TheAppleFreak]

Hmm, that's an interesting issue. All of the issues that I've seen relating to Slack and CORS seem to be specifically in reference to the web API proper, and this package is effectively a light wrapper around Axios that just massages the data a bit before it sends it off. The user agent suggests that you're using this in a browser application (Axios's default user agent appears to be axios/<version>), which might be the culprit; this transport was designed for Node environments and hasn't been tested in browsers to my knowledge.

The replies to this tweet from the Slack API Twitter account indicate that browsers calling the webhooks seems to be a bit of a recurring problem. I'll see if I can find a solution that I can implement on my end, but it might not be something that I can fix.

[eloyra]

this transport was designed for Node environments and hasn't been tested in browsers to my knowledge

Yeah after a bit I figured this might be the case. I was approaching Winston and its plugins as a browser logging solution but I've since realized it's mainly for Node environments.

In any case, it would of course be awesome to be able to make this plugin compatible with the browser, so I'll keep an eye on this.

Thanks for taking the time to look into it and reply ❤️