Перевірте, чи конструктор 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 для отримання токена, маршрут якого також потрібно налаштувати.

Схожі статті