ຕັ້ງຄ່າຊ່ອງ gRPC ຂອງ Pub/Sub Java ສຳລັບ HTTP CONNECT

ຕິດຕັ້ງ ProxyDetector ຜ່ານຜູ້ໃຫ້ບໍລິການຊ່ອງ GAX ໂດຍຮັກສາທີ່ຢູ່ເປົ້າໝາຍ ແລະ ຕົວຕົນ TLS ຂອງ Pub/Sub.

ໃຊ້ຜູ້ໃຫ້ບໍລິການຊ່ອງຂອງລູກຄ້າທີ່ສ້າງຂຶ້ນ ເມື່ອການເຊື່ອມຕໍ່ 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 ຂອງຂໍ້ມູນຢືນຢັນນັ້ນ. ມັນຢູ່ນອກຜູ້ໃຫ້ບໍລິການຊ່ອງທີ່ສະແດງຢູ່ນີ້.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ