search

Azure / azure-kusto-dotnet

Azure Data Explorer (Kusto) SDK for .NET
MIT License
8 stars 5 forks source link

Request: support for network proxies in the Ingest client #46

Open davidglassborow opened 3 days ago

davidglassborow commented 3 days ago

Hi, trialing ADX in a corporate environment where a webproxy is required, needing network credentials, trying to ingest data via the SDK. All my calls end up failing with The proxy tunnel request to proxy 'http://mcafeewebproxy:9090/' failed with status code '407'.

I can find no documentation on how to configure the network connection for the Kusto clients, this made worse because source code is not available.

The equivalent feature in e.g. Azure blob client is configured like:

BlobClientOptions options = new()
{
        Transport = new HttpClientTransport(new HttpClientHandler() { Proxy = new WebProxy() { UseDefaultCredentials = true }})
};

I cannot find anything equivalent in IngestClientOptions class. How do I configure network options in Kusto please ?

AsafMah commented 2 days ago

Currently there is no official way to configure it, we will let you know if this gets implemented.

davidglassborow commented 2 days ago

No way to use it in the usual corporation environment ? Unbelievable.

davidglassborow commented 2 days ago

Currently there is no official way to configure it, we will let you know if this gets implemented.

So it there an un-official way?

davidglassborow commented 1 day ago

Support for proxy in the python sdk:

Support for proxy in the java sdk (for AT&T)

vplauzon commented 9 hours ago

If it's important for your use case, we suggest to enter an idea in https://aka.ms/adx.ideas.

Usually SDKs are used in automation servers / services (i.e. not on laptop), but it could make sense to debug in an environment where proxies are mandatory.

davidglassborow commented 8 hours ago

Why do you mention a laptop ? Our requirement is to take telemetry from a secure SCADA system, decompress and re-shape the data, and then push into ADX, from a on-prem service. The usual security requirements are in place requiring all outgoing traffic (to azure or anywhere else) to go through a secure proxy.

Clearly other language SDKs have required this feature, and added it, and similar features exist in other Azure SDKs, as well as Google and AWS offerings.

The situation is made worse because no source is available, so my only option would be to decompile your SDK and make the fix myself, or build my own SDK.

Anyway easy option for me to advise my enterprise client that ADX is not ready for what they need if they want to use dotnet, and look at competitors, which I have done.