SNOW-3032363: Support VSCode remote environments

[sakshamgoyal-01]

snowflake-connector-python/src/snowflake/connector/auth/webbrowser.py

Line 171 in d82300f

logger.debug("step 2: open a browser")

Also fixes https://snowflake.discourse.group/t/how-do-you-make-sso-externalbrowser-work-with-snowflake-extension-in-vs-code-remote-code-server/4159

Can you improve this step by checking for the env var $TERM_PROGRAM, If this is set to vscode, allow pasting the callback URL even if a browser was opened. This makes sure that oauth always works even in remote environments.

[sfc-gh-dszmolka]

hi @sakshamgoyal-01 the thread you linked is from 2+ years ago. many fixes went into the code since then, including

Added the SNOWFLAKE_AUTH_FORCE_SERVER environment variable to force the use of the local-listening server when using the externalbrowser auth method.
This allows headless environments (like Docker or Airflow) running locally to auth via a browser URL.

in 4.1.0

if you're seeing any issue, would it be possible to provide us with the exact reproduction steps which when executed on our end, leads to the issue you're seeing?

Thank you !

[sakshamgoyal-01]

I have not seen this anywhere in the docs even after searching thoroughly. I think you should add documentation for things like this.

I tried doing this with no success. it still opens a browser (successfully) and I have no way to paste in the redirect url manually. the vscode tunnel does not seem to forward any ports so there is no way for me to make this work at all

[sakshamgoyal-01]

reproduction:

1. open vscode remote ssh session
2. run python code inside session
3. try to use externalbrowser with sso
4. local machine opens browser window
5. local browser authenticates and redirects to localhost
6. remote session is stuck waiting in a loop

[sfc-gh-dszmolka]

thank you, this helps! so per step

5. local machine opens browser window

this might fulfill the check which looks for whether the browser could be opened or not and treats it yes, browser could be opened, and we might never get to the part which would allow for the manual URL input fallback (although those logs weren't shared yet so not sure)

Can you try some hack around this, like

from unittest.mock import patch
import snowflake.connector

with patch('snowflake.connector.auth.webbrowser.webbrowser.open_new', return_value=False):
    conn = snowflake.connector.connect(
        user='your_user',
        account='your_account',
        authenticator='externalbrowser'
    )

or something similar which could force the 'did the browser open' check to return always False thus allow the manual URL input fallback to be reached?

Anyhow, the team will look into this enhancement request (without a timeline attached for implementation) but in parallel if it's within your options to submit a PR for this, your contribution would be appreciated.

edit: of course other workaround could be using non-externalbrowser authentication methods like PAT, keypair, and so on.

[sakshamgoyal-01]

Yes, the patch worked.

another point is my local machine is windows11, the remote ssh is on linux. Not sure if that makes a difference

[sfc-gh-dszmolka]

Good to hear it worked ! And thank you for the extra info, i'll try to test this scenario as well when I get to testing (i have possible fix in mind #2755 which is entirely untested at this moment )

[nataziel]

I think this might be caused by something on the vscode side. I commonly use devcontainers, and when running code that tries to use externalbrowser to connect it is pretty inconsistent on whether it will work or not. Seems to do with whether vscode automatically detects and forwards the correct ports from the container. Generally it is pretty consistent at being able to open a browser window on the host machine, but sporadically can't receive the saml token