b2-sdk-httpclient ignoring proxy settings, could not access API

[anti1869]

Hello.

I am deploying b2 client application behind proxy and it is unable to contact Backblaze API endpoints.
My proxy is definitely working as I have no problems contacting other hosts with other clients.

I believe cause of this is because Apache commons http client does not checking default proxy selector and this means the System Properties like https.proxyHost and https.proxyPort are ineffective.

Since Apache HttpClient seems to have its own way to configure proxies it would be nice to have some of its interface exposed to allow proxy configuration.

As I understood from the docs, it could be done e.g. with RequestConfig.custom().setProxy(new HttpHost(...)), or making HttpClientBuilder use system properties, or some other method.

If this problem could be solved with some other solution, could you please tell me? Thank you.

[certainmagic]

Hi anti1869 --

Sorry for the delayed response. I was backpacking last week.

We are (slowly) working on an implementation of our B2WebApiClient which is built on top of Java's URLConnection class instead of Apache's HttpClient library. If that were available would it you be interested in using it instead of the Apache implementation?

thanks,
ab

[anti1869]

Sure, anything that works. I actually made a workaround bundling my tweaked implementation of webApiHttpClient where I read proxy settings in HttpClientFactoryImpl. I also had to re-enable http connections there, because my app talks to proxy over http.

[certainmagic]

Ok. It sounds like you have unblocked yourself. I will ask someone to update this issue when the new non-Apache implementation becomes available. I feel compelled to point out that we really, really discourage the use of plain HTTP with our APIs because requests contain sensitive information including your application key's secret. If someone can snoop on the traffic between your application and your proxy, they will be able to grab your credentials and use them to impersonate you. It sounds like you know what you're doing, so I trust that you have considered this risk. thanks, ab

…

On Wed, Sep 9, 2020 at 3:18 PM Dmitry Litvinenko ***@***.***> wrote: Sure, anything that works. I actually made a workaround bundling my tweaked implementation of webApiHttpClient where I read proxy settings in HttpClientFactoryImpl. I also had to re-enable http connections there, because my app talks to proxy over http. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHJFCSMM3UMB4UBKYTYR7TSE6MEVANCNFSM4QO5LHWQ> .

[anti1869]

It’s just standard CONNECT tunneling through Squid http proxy. Traffic itself is encrypted. I believe pretty common scheme.

[certainmagic]

Great. :)

…

On Wed, Sep 9, 2020 at 7:20 PM Dmitry Litvinenko ***@***.***> wrote: It’s just standard CONNECT tunneling through Squid http proxy. Traffic itself is encrypted. I believe pretty common scheme. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHJFCTY3PJWE2EH2GYVBLDSE7IQTANCNFSM4QO5LHWQ> .