Tables बिल्डरला पूर्ण HTTP पाइपलाइन मिळते का ते तपासा. ते इनपुट त्याच्या वेगळ्या httpClient पर्यायाला ओव्हरराइड करते; जर अनुप्रयोगाकडे पाइपलाइन असेल, तर ती पाइपलाइन तयार करताना प्रॉक्सी-जाणकार ट्रान्सपोर्ट कॉन्फिगर करा.

थेट Netty HTTP क्लायंट इनपुटसाठी, ट्रान्सपोर्ट तयार करा आणि तो Tables ला द्या:

ProxyOptions proxy = new ProxyOptions(
    ProxyOptions.Type.HTTP,
    new InetSocketAddress("proxy.example.net", 8080)
);
proxy.setCredentials(proxyUser, proxyPassword);

HttpClient transport = new NettyAsyncHttpClientBuilder()
    .proxy(proxy)
    .build();

TableClient tables = new TableClientBuilder()
    .connectionString(storageConnectionString)
    .tableName("records")
    .httpClient(transport)
    .buildClient();

येथे HttpClient म्हणजे com.azure.core.http.HttpClient. इतर प्रकार Azure Core HTTP/Netty, Azure Data Tables आणि java.net.InetSocketAddress मधून येतात. अनुप्रयोग कॉन्फिगरेशन आणि क्रेडेन्शियल व्हेरिएबल्स पुरवतो.

ProxyOptions.Type.HTTP मध्यस्थ निवडतो; setCredentials त्याचे खाते पुरवतो आणि प्रमाणीकरण नसलेल्या एंडपॉइंटसाठी वगळले जाऊ शकते. त्या कॉन्फिगरेशनमध्ये HTTP प्रॉक्सी यादीतील नोंद अनुमत सार्वजनिक Tables एंडपॉइंट मार्गासाठी पत्ता देऊ शकते; ट्रान्सपोर्टवर कोणतेही प्रॉक्सी क्रेडेन्शियल ठेवू नका. स्टोरेज कनेक्शन स्ट्रिंग अजूनही Tables सेवा निवडते.

हे कनेक्शन-स्ट्रिंग प्रमाणीकरण वापरते. ओळख-क्रेडेन्शियल व्यवस्थेत टोकन मिळवण्यासाठी वेगळा HTTP क्लायंट असू शकतो, ज्याचा मार्गही कॉन्फिगर करावा लागतो.

संबंधित लेख