Ipinapasa ng Snowpark Scala ang mga opsyon ng proxy sa kanyang koneksyon sa JDBC

Kumokonekta ang Snowpark Scala gamit ang driver ng Snowflake JDBC. Tumatanggap ang session builder nito ng mga property ng configuration ng JDBC, kaya ang mga setting ng proxy ay makakasama ng umiiral na mapa ng koneksyon:

val proxyOptions = Map(
  "useProxy" -> "true",
  "proxyHost" -> "proxy.example",
  "proxyPort" -> "8080"
)

val session = com.snowflake.snowpark.Session.builder
  .configs(connectionOptions ++ proxyOptions)
  .create

connectionOptions ay naglalaman ng account, authentication at iba pang setting na ginagamit na ng application. Mga entry ito sa string-map ng Scala; ang hostname ng proxy ay walang URL scheme o port nito. Para sa pinapayagang rutang public-proxy na walang authentication ng proxy, pumili ng host at port mula sa listahan ng HTTP proxy habang pinapanatili ang mga setting ng account ng Snowflake.

Idinodokumento rin ng Snowflake JDBC ang proxyUser at proxyPassword para sa intermediate na account. Ibigay ang mga ito sa pamamagitan ng umiiral na pinagmulan ng kredensyal ng application kapag kailangan.

Gumagamit ang nonProxyHosts ng JDBC ng mga pattern na pinaghihiwalay ng patayong linya na may suporta sa wildcard. Sa halaga ng mapa, ang separator ay literal na |; ang URL encoding ay nagiging mahalaga kapag bumubuo ng JDBC URL. Huwag itong palitan ng sintaks na NO_PROXY ng ibang kliyente na pinaghihiwalay ng kuwit.

Panatilihing partikular sa Snowpark Scala ang configuration na ito. Ang Snowpark Python at ang connector ng Snowflake para sa Spark ay may ibang interface ng koneksyon at pangalan ng opsyon.

Hinihiling ng Snowflake na dumaan ang certificate ng serbisyo sa proxy nang walang pagpapalit. Ang rutang HTTP CONNECT at inspeksyon ng TLS ay magkaibang kaayusan; ang proxy na muling naglalabas ng certificate ng Snowflake ay hindi tumutugon sa kahilingang iyon.