შეამოწმეთ, იღებს თუ არა 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 კლიენტი ტოკენის მისაღებად, რომლის მარშრუტიც უნდა დაკონფიგურირდეს.

დაკავშირებული სტატიები