Използвайте доставчика на канал на генерирания клиент, когато връзката 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 маршрута на тези данни. Той е извън показания тук доставчик на канал.

Подобни статии