-
Notifications
You must be signed in to change notification settings - Fork 892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Native proxy support without providing custom SocketFactory #575
Comments
@a-zink im trying hard currently to make mqtt client work behind a proxy. using a proxy from https://free-proxy-list.net 62.99.67.216:8080 in the mqtt client connect options i then use a custom ssl socket factory (see below) btw im also using mqttConnectOptions.setSSLHostnameVerifier(NoopHostnameVerifier.INSTANCE); does the broker always(by default) support mqtt over websockets or has this feature to be enabled? For any help i would be more than grateful, as i am seriously running out of ideas here currently i am using the following custom ssl socket factory (modified from the link): `/**
*/
} |
I'm also interested in a solution to this. I am currently blocked on using paho due to this |
@dasAnderl did you ever figure this out? I have been trying your solution and was able to perform SSL handshake with the server, but then paho gave me |
@dasAnderl @AndrewJudson please see my comment #573 (comment) |
Yes, the broker of course needs to support websockets. |
@a-zink here the working custom factory in kotlin:
|
Is this feature supported yet? This is a blocking issue for many. |
Hello, I tried the solution given by dasAnderl, but I am getting I am currently blocked due to this issue, any help is greatly appreciated, Thanks! |
#1010 |
The client allows to set a custom SocketFactory which allows the connection to be established over a proxy. However this is quite cumbersome. Using a proxy should be an easy-to-use feature of the client because this is a quite common use-case. Especially for mqtt over websockets, which is already supported.
There are basically two use-cases for mqtt over websockets
(also see introduction chapter in amqp over websockets which is a related topic)
As this is the Java mqtt client, browser support is not the target use-case for websockets. Hence I argue that the only reason for using the websocket feature is network restrictions. However this feature is somehow incomplete without native proxy support.
Also see
#573
#319 (Only addresses socks proxy)
#419 (Seems to be a proxy auth issue. I would say this is out of scope, as workarounds like cntlm exist)
The text was updated successfully, but these errors were encountered: