Használja a generált kliens csatornaszolgáltatóját, amikor egy Pub/Sub Java gRPC-kapcsolatnak HTTP CONNECT proxyra van szüksége. Egy szokásos URLConnection-beállítás nem hozza létre ezt a csatornakonfigurációt.

A topic-admin klienshez:

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.
}

A TopicAdminClient és a TopicAdminSettings Pub/Sub v1 osztályok; a HttpConnectProxiedSocketAddress a io.grpc-ből, a InetSocketAddress a java.net-ből származik. A példa a csatorna által használt szokásos internetcím-célt feltételezi.

Az érzékelő a proxykapcsolat címét az eredeti céllal együtt adja vissza. A gRPC-építő megköveteli, hogy a proxy címe feloldódjon. Hagyja a szolgáltatás végpontját Pub/Subként: a proxy gazdagépnevével való helyettesítés elveszítené a szolgáltatás célját és a tervezett TLS-identitást.

Távolítsa el a felhasználónév/jelszó hívásokat hitelesítés nélküli proxy esetén; nyilvános HTTP-jelöltek a HTTP-proxyk listájából érhetők el. Ezek a hívások a HTTP CONNECT hitelesítőadat-felülete, nem SOCKS és nem általános NTLM-megvalósítás.

Ha a hiba a gRPC-művelet előtt jelentkezik, miközben egy önállóan létrehozott hitelesítő adat tokent szerez, vizsgálja meg annak a hitelesítő adatnak a HTTP-útvonalát. Az a itt bemutatott csatornaszolgáltatón kívül esik.

Kapcsolódó cikkek