Le connecteur Snowflake pour Python 5 prend en charge des champs de proxy au niveau de la connexion. Pour une application qui conserve ses options de connexion habituelles séparément :

connection = snowflake.connector.connect(
    **connection_options,
    proxy_host='proxy.example',
    proxy_port=8080,
    use_proxy_env=False,
)

connection_options contient les réglages existants du compte Snowflake et de l'authentification, sans clés de proxy en double. proxy_user et proxy_password fournissent un compte intermédiaire distinct lorsque c'est nécessaire. Pour une route de proxy public autorisée sans ce compte, prenez des valeurs candidates de proxy_host et proxy_port dans la liste de proxys HTTP.

Par défaut, use_proxy_env vaut vrai et le connecteur lit HTTP_PROXY, HTTPS_PROXY et NO_PROXY. Dans la version 5, un proxy_host ou un proxy_port explicite est prioritaire sur ces valeurs d'environnement. Définir use_proxy_env=False désactive délibérément leur usage.

Le comportement documenté depuis 3.17.0 mais avant la version 5 laissait les valeurs d'environnement primer sur l'hôte et le port explicites. Conservez la version du connecteur avec une comparaison entre déploiements.

Snowflake exige aussi que son certificat passe sans modification d'interception. Une route via le proxy d'entreprise n'autorise pas à remplacer le certificat du service par un certificat d'inspection arbitraire.

Pour les contournements, NO_PROXY accepte des suffixes d'hôte ou des adresses IP séparés par des virgules, et non des expressions à joker. Configurez l'environnement réel du worker Python lors de l'utilisation de cette route, y compris un worker Django ou un processus de notebook.

Articles similaires