Наладка gRPC-канала Pub/Sub Java для HTTP CONNECT

Усталюйце ProxyDetector праз правайдэр канала GAX, захоўваючы адрас мэты Pub/Sub і ідэнтычнасць TLS.

Выкарыстоўвайце правайдэр канала згенераванага кліента, калі злучэнню 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-маршрут гэтых уліковых даных. Ён па-за межамі паказанага тут правайдэра канала.

Падобныя артыкулы