It gRPC-kanaal fan Pub/Sub Java foar HTTP CONNECT konfigurearje
Ynstallearje in ProxyDetector fia de GAX-kanaalprovider, en hâld it doeladres en de TLS-identiteit fan Pub/Sub yntakt.
Brûk de kanaalprovider fan 'e generearre kliïnt as in Pub/Sub Java gRPC-ferbining in HTTP CONNECT-proxy nedich hat. In gewoane URLConnection-ynstelling makket dizze kanaalkonfiguraasje net.
Foar de 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 binne Pub/Sub v1-klassen; HttpConnectProxiedSocketAddress komt fan io.grpc en InetSocketAddress fan java.net. It foarbyld giet út fan it gewoane ynternetadresdoel dat dit kanaal brûkt.
De detektor jout in proxyferbiningsadres njonken it oarspronklike doel werom. De gRPC-bouwer easket dat it proxyadres oplost wurdt. Lit it tsjinst-einpunt Pub/Sub bliuwe: it ferfangen troch de proxyservernamme soe it tsjinstdoel en de bedoelde TLS-identiteit ferlieze.
Ferwiderje de brûkersnamme/wachtwurd-oproppen foar in net-authentisearre proxy; publike HTTP-kandidaten steane yn 'e list mei HTTP-proxy's. Dy oproppen binne de HTTP CONNECT-legitimaasje-ynterface, net SOCKS of in algemiene NTLM-ymplemintaasje.
As de flater foar de gRPC-operaasje bard is wylst in selsstannich oanmakke legitimmaasje in token krijt, ûndersykje dan de HTTP-rûte fan dy legitimmaasje. Dy leit bûten de hjir sjen litten kanaalprovider.