SNOW-1299307: Refused to set unsafe header on v1.9.0+

[cimd]

Please answer these questions before submitting your issue.
In order to accurately debug the issue this information is required. Thanks!

1. What version of NodeJS driver are you using?
   18.20.0

2. What operating system and processor architecture are you using?
   Windows 11 intel x64

3. What version of NodeJS are you using?
   (node --version and npm --version)
   node 18.20.0
   npm 10.5.0

4. What are the component versions in the environment (npm list)?

5.Server version:* E.g. 1.90.1
This error exists for any versions including and above v1.9.0

6. What did you do?

Connecting to snowflake using 'EXTERNALBROWSER'.

  snowflake = (<any>window).snowflake.sdk.createConnection(
    // connection options
    {
      account: 'XXXX-XXX',
      username: authStore.user.email,
      database: 'IDSPROD',
      authenticator: 'EXTERNALBROWSER',
      warehouse: 'REPORTING_WH',
      role: 'REPORTING',
      clientSessionKeepAlive: true,
      // clientSessionKeepAliveHeartbeatFrequency: 3600
    }
  )

7. What did you expect to see?

Connected successfully. But starting from v1.9.0, when Axios was bumped to v1.6.0, there is an error when trying to set the user-agent header.

8. Can you set logging to DEBUG and collect the logs?

   https://community.snowflake.com/s/article/How-to-generate-log-file-on-Snowflake-connectors

e.g
Add this to get standard output.

var snowflake = require('snowflake-sdk');
snowflake.configure(
{
  logLevel: 'trace'
});

9. What is your Snowflake account identifier, if any? (Optional)

[sfc-gh-dszmolka]

hi and thank you for submitting this issue. We don't see this error on node.js, for which framework this driver is intended and against which we test.
Can confirm that the user-agent header (in which we send the driver version) is successfully set and is visible on the Snowflake queries on the backend.

Given this is an error coming from axios, i'm not entirely sure on the lengths we can go to fix it but I'm happy to take a stab at it if you could please provide a hint on the reproduction setup which needs to be installed in order to get to the issue..

[cimd]

Hi,
This is for node. The pictures come from an electron app. Tested on both node18 and node20. The connection is never completed as the error prevents even the authentication, so there are no headers sent.
I'll try to create a demo repo, as I can't share our production code here.

[sfc-gh-dszmolka]

having a minimal viable repro would be massively appreciated; especially if it really happens with 'just node' too. I was under the impression this comes from a browser situation especially now mentioning Electron, but if not, then it's possibly quite impactful. Thank you for the repro in advance ! 👍

[cimd]

Try this repo: https://github.com/cimd/snowflake-demo

Just run:

1. yarn install
2. yarn dev

[sfc-gh-dszmolka]

thank you - will check it out now. In the meantime, maybe it could be a good idea to sanitize the code and remove any possible sensitive info like username, account, etc.

[sfc-gh-dszmolka]

managed to install and run the project (thank you again for the repro) and this is definitely not a 'just node' situation :) for which we build and test this driver.

stuck at the point tho where the server is up, port is forwarded out (i'm using it from a container) but opening localhost:9300 doesn't create the error but instead errors our with client-entry.js:106 [Quasar] boot error: TypeError: Cannot read properties of undefined (reading 'sdk')

so could not yet get to the error you're seeing. Any suggestions perhaps how to get past this ?

[cimd]

Hummm... From the error, it seems that Electron's pre-load script wasn't loaded.

Did you run quasar dev or yarn dev? The first will open the project in browser mode (non nodejs). The second will open it in electron mode (nodejs env).

[sfc-gh-dszmolka]

as suggested in this comment, was using yarn dev

actually , a modified version, quasar dev -m electron -- --no-sandbox --disable-setuid-sandbox instead quasar dev -m electron behind yarn dev , otherwise the startup would exit with

[0403/124431.797906:FATAL:electron_main_delegate.cc(295)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.

as it doesn't allow to be run as root.
To make sure it doesn't have to do with the user who owns the process, created a non-root user and run the yarn dev (the original yarn dev == quasar dev -m electron. Same result unfortunately.

[cimd]

I can see you've found Quasar's Electron configuration page. But it looks like you're still running as a root user.
I've tried running as root here and got the same error as you. I'm afraid I don't know how to prevent it besides running as a non-root user.

[sfc-gh-dszmolka]

sadly , as mentioned in the above comment, no change in the error message
client-entry.js:106 [Quasar] boot error: TypeError: Cannot read properties of undefined (reading 'sdk')

even when running as a non-root user

# ps -ejf
UID        PID  PPID  PGID   SID  C STIME TTY          TIME CMD
root         1     0     1     1  0 Apr03 pts/0    00:00:00 /bin/bash
root      2081     1  2081     1  0 Apr03 pts/0    00:00:01 Xvfb -ac :99 -screen 0 1280x1024x16
root      3117     1  3117     1  0 Apr03 pts/0    00:00:00 su - testuser
testuser  3118  3117  3118     1  0 Apr03 pts/0    00:00:00 -bash
testuser  3156     1  3121     1  1 Apr03 pts/0    00:11:03 /snowflake-demo/node_modules/esbuild-linux-64/bin/esbuild --service=0.14.51 --ping
testuser  3437  3118  3437     1  3 06:42 pts/0    00:00:01 node /opt/yarn-v1.22.19/bin/yarn.js dev
testuser  3458  3437  3437     1  0 06:42 pts/0    00:00:00 /bin/sh -c quasar dev -m electron
testuser  3459  3458  3437     1 81 06:42 pts/0    00:00:31 /usr/local/bin/node /snowflake-demo/node_modules/.bin/quasar dev -m electron
testuser  3472  3459  3437     1  2 06:42 pts/0    00:00:00 /snowflake-demo/node_modules/esbuild-linux-64/bin/esbuild --service=0.14.51 --ping
testuser  3485  3459  3437     1 10 06:42 pts/0    00:00:03 /snowflake-demo/node_modules/electron/dist/electron --inspect=5858 /snowflake-demo/.quasar/electron/electron-main.js
testuser  3488  3485  3437     1  0 06:42 pts/0    00:00:00 /snowflake-demo/node_modules/electron/dist/electron --type=zygote --no-zygote-sandbox
testuser  3489  3485  3437     1  0 06:42 pts/0    00:00:00 /snowflake-demo/node_modules/electron/dist/electron --type=zygote
testuser  3491  3489  3437     1  0 06:42 pts/0    00:00:00 /snowflake-demo/node_modules/electron/dist/electron --type=zygote
testuser  3525  3485  3437     1  1 06:42 pts/0    00:00:00 /snowflake-demo/node_modules/electron/dist/electron --type=utility --utility-sub-type=network.mojom.NetworkService --lang=en-US --service-sandbox-type=none --enabl
testuser  3536  3485  3437     1  8 06:42 pts/0    00:00:02 /snowflake-demo/node_modules/electron/dist/electron --type=renderer --enable-crash-reporter=8396da24-726b-4066-a7d7-9642039e10fb,no_channel --user-data-dir=/home/t
testuser  3537  3491  3437     1 10 06:42 pts/0    00:00:03 /snowflake-demo/node_modules/electron/dist/electron --type=renderer --enable-crash-reporter=8396da24-726b-4066-a7d7-9642039e10fb,no_channel --user-data-dir=/home/t
testuser  3591  3488  3437     1  1 06:42 pts/0    00:00:00 /snowflake-demo/node_modules/electron/dist/electron --type=gpu-process --enable-crash-reporter=8396da24-726b-4066-a7d7-9642039e10fb,no_channel --user-data-dir=/hom
testuser  3629  3459  3437     1  1 06:42 pts/0    00:00:00 /snowflake-demo/node_modules/vite/node_modules/esbuild-linux-64/bin/esbuild --service=0.14.54 --ping
root      3666     0  3666  3666  0 06:43 pts/1    00:00:00 /bin/bash
root      3672  3666  3672  3666 99 06:43 pts/1    00:00:00 ps -ejf

so without a working repro, for an issue which happens outside of the framework for which we claim support, I'm not really sure how to proceed. Besides perhaps directly filing this axios bug with axios so they could address it.

I'll try to run this in a non-containerized environment to see if it makes a difference.

[sfc-gh-dszmolka]

Okay, running the repro on a 'fat' and Windows host allowed me to see the issue (amongst other, more serious issues like CORS ..)

It looks like related to Electron and a quick search in axios bugs pointed me to this (closed, but still unfixed) axios bug where the commenter describes the exact situation you're in.

As mentioned initially, not much we can do from snowflake-sdk, especially considering

1. this behaviour (setting the client environment and client application in User-Agent and sending to Snowflake) is consistent across all Snowflake drivers (Python, Go, Java, etc.) and we don't intend to change it.
2. issue only seems to affect Electron apps (or possibly other setup with similar architecture)
3. Furthermore, the same issue in Electron is reproducible even without Snowflake, using another SDK which also tries to set the user-agent as part of their behaviour; see the axios issue's comment I referenced above, where the guy seems to have it from Slack without Snowflake

A possible solution for you particularly, if this Refused to set unsafe header "user-agent" really prevents the authentication request from even being sent in the first place, would be perhaps locally patching relevant axios module . Thread linked above has a possible way to do it.

Hope this helps.

[sfc-gh-dszmolka]

marking this issue as closed for now per the above