Is it possible to use emqttc https://github.com/emqtt/emqttc when behind a proxy?
You can pass SSL options to the emqttc:start_link function but it doesn't appear to do anything for a proxy. As an example I've tried using {proxy_auth,{Proxy_Username, Proxy_Password}} as an option. Any suggestions on if this is possible or how to configure it for proxy use?
You can not use a HTTP proxy to forward native MQTT connections, they are 2 totally different protocols.
You could forward MQTT over Websockets, but it does not appear that emttc supports MQTT over Websockets.
Related
I have a WebSocket server running on an Android device on my local network. I would like to have the ability to discover this server using DNS-based Service Discovery (DNS-SD). I believe this is possible for plain sockets but is this possible for WebSockets? If not, are there any other mechanisms besides DNS-SD that would allow me to discover a WebSocket server on a LAN besides iterating through all possible IP:port combinations? If this is possible, how can I go about naming my service so that it is discoverable?
I'm trying to analyse what information an app is sending so I setup Charles but to my surprise nothing was logged out.
After decompiling the app I see that it doesn't use simple REST calls but rather a library called gRPC.
Is there a good tool out there that will allow me too see what is send out from the app?
The Mediator is a Cross-platform GUI gRPC debugging proxy like Charles but design for gRPC.
You can dump all gRPC requests without any configuration.
Mediator can render the binary message into a JSON tree, when you have the API schema.
It support decode gRPC/TLS, but you should download and install the Mediator Root Certificate to your device.
gRPC uses HTTP/2 as a transport protocol. Any proxy which supports HTTP/2 for both the front-end and back-end connections should be able to be used to inspect the packets a gRPC connection. Note, some proxies only support HTTP/2 for the front-end or back-end connections and those are incompatible with gRPC.
Envoy Proxy (https://www.envoyproxy.io/) supports proxying gRPC connections and can be configured to log out request information.
Some other example proxies include:
Nginx https://medium.com/nirman-tech-blog/nginx-as-reverse-proxy-with-grpc-820d35642bff
https://github.com/mwitkow/grpc-proxy
https://github.com/mercari/grpc-http-proxy
If you are asking for android there is a app called HttpCanry. It can log request/ respond.
If UDP is blocked, i need to enable HTTP(s) fallback with aspera connect plugin thru HAProxy. Has anyone successfully done this ? I have read all the documentation but there is nothing that describes the HAProxy use case
I assume you talk about a client side forward proxy.
If you use the IBM Aspera Connect Client, it comes with HTTP (forward) proxy configuration.
http://download.asperasoft.com/download/docs/connect/3.9.6/user_osx/webhelp/index.html#dita/network_environment.html
This will work when the client falls back to HTTP.
Note that the client will fallback to HTTP only if this feature is enabled on the server side.
You can see that by examining the parameters provided to the client by the browser (put in dev mode). In that case, it has http parameters (port).
Typically, parameter: https_fallback_port
If not, then there is no possible http fallback, and it will not use the (forward) proxy.
If you are talking about reverse proxy in front of a server configured with fallback, this is part of the (public) documentation of the IBM Aspera Proxy.
Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose of using existing web/HTTP infrastructures? And I think it no longer fits the name WebSocket on non-80 ports.
If I use WebSocket over other ports, why not just use TCP directly? Or is there any special benefits in the WebSocket protocol itself?
And since current WebSocket handshake is in the form of a HTTP UPGRADE request, does it mean I have to enable HTTP protocol on the port so that WebSocket handshake can be accomplished?
Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose
of using existing web/HTTP infrastructures? And I think it no longer
fits the name WebSocket on non-80 ports.
You can run a webSocket server on any port that your host OS allows and that your client will be allowed to connect to.
However, there are a number of advantages to running it on port 80 (or 443).
Networking infrastructure is generally already deployed and open on port 80 for outbound connections from the places that clients live (like desktop computers, mobile devices, etc...) to the places that servers live (like data centers). So, new holes in the firewall or router configurations, etc... are usually not required in order to deploy a webSocket app on port 80. Configuration changes may be required to run on different ports. For example, many large corporate networks are very picky about what ports outbound connections can be made on and are configured only for certain standard and expected behaviors. Picking a non-standard port for a webSocket connection may not be allowed from some corporate networks. This is the BIG reason to use port 80 (maximum interoperability from private networks that have locked down configurations).
Many webSocket apps running from the browser wish to leverage existing security/login/auth infrastructure already being used on port 80 for the host web page. Using that exact same infrastructure to check authentication of a webSocket connection may be simpler if everything is on the same port.
Some server infrastructures for webSockets (such as socket.io in node.js) use a combined server infrastructure (single process, one listener) to support both HTTP requests and webSockets. This is simpler if both are on the same port.
If I use WebSocket over other ports, why not just use TCP directly? Or
is there any special benefits in the WebSocket protocol itself?
The webSocket protocol was originally defined to work from a browser to a server. There is no generic TCP access from a browser so if you want a persistent socket without custom browser add-ons, then a webSocket is what is offered. As compared to a plain TCP connection, the webSocket protocol offers the ability to leverage HTTP authentication and cookies, a standard way of doing app-level and end-to-end keep-alive ping/pong (TCP offers hop-level keep-alive, but not end-to-end), a built in framing protocol (you'd have to design your own packet formats in TCP) and a lot of libraries that support these higher level features. Basically, webSocket works at a higher level than TCP (using TCP under the covers) and offers more built-in features that most people find useful. For example, if using TCP, one of the first things you have to do is get or design a protocol (a means of expressing your data). This is already built-in with webSocket.
And since current WebSocket handshake is in the form of a HTTP UPGRADE
request, does it mean I have to enable HTTP protocol on the port so
that WebSocket handshake can be accomplished?
You MUST have an HTTP server running on the port that you wish to use webSocket on because all webSocket requests start with an HTTP request. It wouldn't have to be heavily featured HTTP server, but it does have to handle the initial HTTP request.
Yes - Use 443 (ie, the HTTPS port) instead.
There's little reason these days to use port 80 (HTTP) for anything other than a redirection to port 443 (HTTPS), as certification (via services like LetsEncrypt) are easy and free to set up.
The only possible exceptions to this rule are local development, and non-internet facing services.
Should I use a non-standard port?
I suspect this is the intent of your question. To this, I'd argue that doing so adds an unnecessary layer of complication with no obvious benefits. It doesn't add security, and it doesn't make anything easier.
But it does mean that specific firewall exceptions need to be made to host and connect to your websocket server. This means that people accessing your services from a corporate/school/locked down environment are probably not going to be able to use it, unless they can somehow convince management that it is mandatory. I doubt there are many good reasons to exclude your userbase in this way.
But there's nothing stopping you from doing it either...
In my opinion, yes you can. 80 is the default port, but you can change it to any as you like.
I've had a search over the internet but can't seem to find any straightforward instructions on how to use the Thrift protocol from behind a proxy.
To give you a bit of background - we have a Zipkin instance setup (https://github.com/twitter/zipkin) that uses a Cassandra instance (http://cassandra.apache.org/) to store Zipkin traces. Our intention is to negotiate over the thrift protocol to a collector that is then responsible for writing traces to Cassandra.
What conditions have to be in place for us to negotiate successfully via our corporate proxy? Do we just have to set certain proxy properties when trying to negotiate or do we have to set something else up that allows this negotiation to happen?
Any help people can give in this direction with regards to resources and/or an answer would be greatly appreciated.
The Apache Thrift TSocketTransport (almost certainly what you are using) uses TCP on a configurable port. Cassandra usually uses port 9160 for thrift. When using Thrift/TCP no HTTP setup is necessary. Just open 9160 (and any other ports your custom thrift servers may be listening on).
Though you can use Thrift over HTTP, Thrift is RPC, not REST, so proxy caching will cause problems, the client needs a direct comm channel with the server.
If you do need to access a thrift service via a proxy, something like this would work:
https://github.com/totally/thrift_goodies/blob/master/transport.py
You can kill the kerberos stuff if you don't need that.