Set opp gRPC-kanalen til Pub/Sub Java for HTTP CONNECT

Bruk kanalleverandøren til den genererte klienten når ei Pub/Sub Java gRPC-tilkopling treng ein HTTP CONNECT-proxy. Ei vanleg URLConnection-innstilling etablerer ikkje denne kanalkonfigurasjonen.

For topic-admin-klienten:

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 og TopicAdminSettings er Pub/Sub v1-klassar; HttpConnectProxiedSocketAddress kjem frå io.grpc og InetSocketAddress frå java.net. Dømet føreset det vanlege internettadressemålet som denne kanalen brukar.

Detektoren returnerer ei proxyforbindingsadresse saman med det opphavlege målet. gRPC-byggjaren krev at proxyadressa blir løyst opp. Lat endepunktet til tenesta vera Pub/Sub: å byta det ut med vertsnamnet til proxyen ville mista tenestemålet og den tiltenkte TLS-identiteten.

Fjern brukarnamn-/passordkalla for ein proxy utan autentisering; offentlege HTTP-kandidatar finst i lista over HTTP-proxyar. Desse kalla er HTTP CONNECT-legitimasjonsgrensesnittet, ikkje SOCKS eller ei generell NTLM-implementering.

Viss feilen oppstår før gRPC-operasjonen medan ein sjølvstendig oppretta legitimasjon får eit token, gransk HTTP-ruta til den legitimasjonen. Ho ligg utanfor kanalleverandøren som er vist her.