Stel Pub/Sub Java se gRPC-kanaal vir HTTP CONNECT op

Gebruik die gegenereerde kliënt se kanaalverskaffer wanneer 'n Pub/Sub Java gRPC-verbinding 'n HTTP CONNECT-proxy nodig het. 'n Gewone URLConnection-instelling vestig nie hierdie kanaalkonfigurasie nie.

Vir die topic-admin-kliënt:

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 en TopicAdminSettings is Pub/Sub v1-klasse; HttpConnectProxiedSocketAddress kom uit io.grpc en InetSocketAddress uit java.net. Die voorbeeld aanvaar die gewone internetadres-teiken wat hierdie kanaal gebruik.

Die detektor gee 'n proxyverbindingsadres saam met die oorspronklike teiken terug. Die gRPC-bouer vereis dat die proxyadres opgelos word. Laat die diensendpunt as Pub/Sub: om dit met die proxy-gasheernaam te vervang, sal die diensteiken en die beoogde TLS-identiteit verloor.

Verwyder die gebruikersnaam/wagwoord-oproepe vir 'n ongeverifieerde proxy; openbare HTTP-kandidate is in die HTTP-instaanbedienerlys te vind. Daardie oproepe is die HTTP CONNECT-geloofsbriefkoppelvlak, nie SOCKS of 'n algemene NTLM-implementering nie.

As die fout voor die gRPC-bewerking plaasvind terwyl 'n onafhanklik geskepte geloofsbrief 'n token verkry, ondersoek daardie geloofsbrief se HTTP-roete. Dit val buite die kanaalverskaffer wat hier gewys word.