Tables क्लाइंट के लिए Azure Java Netty ProxyOptions
प्रमाणित Netty HTTP ट्रांसपोर्ट बनाएँ और उसे Azure Tables क्लाइंट बिल्डर को दें।
जाँचें कि 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 क्लाइंट हो सकता है, जिसका मार्ग भी कॉन्फ़िगर करना होगा।