Налаштування gRPC-каналу Pub/Sub Java для HTTP CONNECT

Установіть ProxyDetector через постачальника каналу GAX, зберігши цільову адресу й TLS-ідентичність Pub/Sub.

Використовуйте постачальника каналу згенерованого клієнта, коли з'єднанню Pub/Sub Java gRPC потрібен проксі HTTP CONNECT. Звичайне налаштування URLConnection не створює такої конфігурації каналу.

Для клієнта topic-admin:

var channelProvider = TopicAdminSettings
    .defaultGrpcTransportProviderBuilder()
    .setChannelConfigurator(channel -> channel.proxyDetector(target ->
        HttpConnectProxiedSocketAddress.newBuilder()
            .setProxyAddress(new InetSocketAddress("proxy.example", 8080))
            .setTargetAddress((InetSocketAddress) target)
            .setUsername(proxyUser)
            .setPassword(proxyPassword)
            .build()))
    .build();

var settings = TopicAdminSettings.newBuilder()
    .setTransportChannelProvider(channelProvider)
    .build();
try (TopicAdminClient client = TopicAdminClient.create(settings)) {
    // Perform the application's intended topic-admin operation here.
}

TopicAdminClient і TopicAdminSettings — класи Pub/Sub v1; HttpConnectProxiedSocketAddress походить з io.grpc, а InetSocketAddress — з java.net. Приклад припускає звичайну ціль у вигляді інтернет-адреси, яку використовує цей канал.

Детектор повертає адресу проксі-з'єднання разом з початковою ціллю. Постачальник gRPC вимагає, щоб адресу проксі було розв'язано. Залиште кінцеву точку служби як Pub/Sub: заміна її іменем хоста проксі втратила б ціль служби та передбачувану TLS-ідентичність.

Видаліть виклики імені користувача/пароля для проксі без автентифікації; публічні кандидати HTTP є в списку HTTP-проксі. Ці виклики — інтерфейс облікових даних HTTP CONNECT, а не SOCKS чи загальна реалізація NTLM.

Якщо збій трапляється до операції gRPC, поки незалежно створені облікові дані отримують токен, перевірте HTTP-маршрут цих даних. Він поза межами показаного тут постачальника каналу.

Схожі статті