بررسی کنید که سازنده Tables یک خط لوله HTTP کامل دریافت می‌کند یا خیر. این ورودی گزینه httpClient جداگانه آن را نادیده می‌گیرد؛ اگر برنامه مالک خط لوله است، انتقال آگاه از پروکسی را هنگام ساخت آن خط لوله پیکربندی کنید.

برای ورودی مستقیم کلاینت HTTP Netty، انتقال را بسازید و آن را به 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 جداگانه‌ای برای دریافت توکن داشته باشد که مسیر آن نیز باید پیکربندی شود.

مقالات مرتبط