I require to interact to RabbitMQ using java client. As, enterprise environment are restrictive for I would require to raise firewall request. But, I came to know for port 443 and HTTPs or HTTP post we don't require firewall.
Is it possible to publish request and get response for RabbitMQ using HTTP Proxy
you can configure the amqp port
cp /usr/share/doc/rabbitmq-server-[rabbitmq version]/rabbitmq.config.example /etc/rabbitmq/rabbitmq.config
Then search for
%%{tcp_listeners, [5672]}
And remove ‘%%’,
change 5672 to opened port, Then restart rabbitmq server.
or you will need to use socks as another solution
Related
I have server application which runs on local host and the client also runs on local host.
As of now I am using java.net.serversocket and any application which has the ip and port detail of server can listen to the port.
My requirement is to secure the ports or secure the communication between the server and client application such that only my application client (authorised) one can listen to the ports or connect to server application. The data sent to and from client and server also has to be secured.
Apologies if naming conventions are not correct. I have been searching for solution and couldn't get anything for this, all I got is how to connect and make application communicate using socket programming , but no where I got the answer as how to secure the communication.
What you need here is some sort of authentication method to authorise only your client to communicate with the server. If you are using an existing communication protocol then it might have a specification for authentication already. If you are using your own protocol then you'll have come up with your own design for authentication.
It could be as simple as the server issuing some sort of request for authentication to the client. The client would then have to provide a satisfactory response (eg a user/password) otherwise the server would close the connection.
I would recommend taking a look at how some other protocols (eg HTTP) handle authentication to get some insight and also understand potential pitfalls.
As a Proxy Program sitting in between Server and Browser , how can we notify a browser to use either http1.1 or http2.0 protocol
The answer depends on whether your "proxy" is a forward proxy configured on the browser, or a reverse proxy configured on the server.
In the first case (forward proxy), because the target scheme is https, the browser will issue a HTTP CONNECT to the forward proxy and the forward proxy will create a tunnel to the server.
Once the tunnel is created, the browser and the server will communicate directly with the forward proxy only forwarding bytes in both directions.
In this case, client and server will negotiate directly the protocol via ALPN because they communicate directly, with the forward proxy only forwarding bytes (but not inspecting or otherwise changing them).
Therefore in this case you don't need to inform the client of anything, because client and server communicate directly.
In the second case (reverse proxy) the browser will connect to the reverse proxy thinking it's its final destination.
For a request to https://example.com, the DNS will resolve the reverse proxy address, and the reverse proxy must offer a valid certificate for example.com.
If the reverse proxy needs to forward the request to a server, then it does not matter what protocol it will use, since the client will never be aware of this communication between the reverse proxy and the server.
If the reverse proxy supports only HTTP/1.1 and the server supports HTTP/2, then the reverse proxy cannot tell the client that the server supports HTTP/2 because the client never talks directly to the server: the client only sees the reverse proxy and because the reverse proxy only supports HTTP/1.1 then they will never be able to speak HTTP/2, even if the server does.
If the reverse proxy supports both HTTP/1.1 and HTTP/2, then the client and the reverse proxy will speak HTTP/2. It does not matter what protocol the reverse proxy speaks to the server: it can be HTTP/1.1, HTTP/2, FastCGI, etc. But the protocol that the reverse proxy uses with the server is of no interest to the client because the client will never be able to talk directly to the server.
The client only ever speaks to the reverse proxy, so the protocol that they negotiate is the only one that matters to the client.
In this case also you don't need to inform the client of anything, because the client can only communicate with the proxy and can only use the protocol that it negotiated with the proxy.
We have a number of Jetty http(s) servers, all behind different firewalls. The http servers are at customer sites (not under our control). Opening ports in the firewalls at these sites is not an option. Right now, these servers only serve JSON documents in response to REST requests.
We have web clients that need to interact with a given http server based on URL parameter or header value.
This seems like a straightforward proxy server situation - except for the firewall.
The approach that I'm currently trying is this:
Have a centralized proxy server (also Jetty based) that listens for inbound registration requests from the remote http servers. The registration request will take the form of a Websocket connection, which will be kept alive as long at the remote HTTP server is available. On registration, the Proxy Server will capture the websocket connection and map it to a resource identifier.
The web client will connect the proxy server, and include the resource identifier in the URL or header.
The proxy server will determine the appropriate Websocket to use, then pass the request on to the HTTP server. So the request and response will travel over the Websocket. Once the response is received, it will be returned to the web client.
So this is all well and good in theory - what I'm trying to figure out is:
a) is there a better way to achieve this?
b) What's the best way to set up Jetty to do the proxying on the HTTP Server end of the pipe?
I suppose that I could use Jetty's HttpClient, but what I really want to do is just pull the HTTP bytes from the websocket and pipe them directly into the Jetty connector. It doesn't seem to make sense to parse everything out. I suppose that I could open a regular socket connection on localhost, grab the bytes from the websocket, and do it that way - but it seems silly to route through the OS like that (I'm already operating inside the HTTP Server's Jetty environment).
It sure seems like this is the sort of problem that may have already been solved... Maybe by using a custom jetty Connection that works on WebSockets instead of TCP/IP sockets?
Update: as I've been playing with this, it seems like another tricky problem is how to handle request/response behavior (and ideally support muxing over the websocket channel). One potential resource that I've found is the WAMP sub-protocol for websockets: http://wamp.ws/
In case anyone else is looking for an answer to this one - RESTEasy has a mocking framework that can be used to invoke the REST functionality without running through a full servlet container: http://docs.jboss.org/resteasy/docs/2.0.0.GA/userguide/html_single/index.html#RESTEasy_Server-side_Mock_Framework
This, combined with WAMP, appears to do what I'm looking for.
i am here looking for resources or sample code for proxy server which can handle both http and https requests written in java. i searched google and found lot of data on how to handle http requests but not https.
A proxy cannot handle HTTPS and still provide end to end security. It is not possible using SSL/TLS which is what HTTPS is built on.
And a proxy that doesn't provide end-to-end security only has limited utility. So I'm not surprised you can't find an existing implementation.
I'm assuming that you want a normal HTTPS proxy here, that is a proxy that will not look into the request but merely relay all the traffic to the actual HTTPS server after the user-agent has used the HTTP CONNECT method. This is how HTTP proxy servers are normally used for HTTPS requests by browsers.
I haven't tried, but you could look at Jetty and its ConnectHandler.
I know my RMI app works correctly - it works fine when the server is on localhost and inside the LAN but when connecting to an external RMI server it fails when trying to make stub calls
So the server is bound to localhost (an internal IP - 192.168.1.73) but the client is specifying an external IP (45.4.234.56) - which then gets forwarded to the internal server. How do you resolve this problem?
thanks
The "simplest" approach is for your network admin to add IP forwarding from a specific port on the firewall to your server.
Assuming this isn't an option (and it probably isn't), then RMI supports tunnelling over HTTP. The performance is poor, but it's much more firewall-friendly.
http://java.sun.com/javase/6/docs/technotes/guides/rmi/faq.html#firewallOut
This well-worn method is popular since
it requires almost no setup, and works
quite well in firewalled environments
which permit you to handle HTTP
through a proxy, but disallow regular
outbound TCP connections.
If Java RMI fails to make a normal (or
SOCKS) connection to the intended
server, and it notices that a HTTP
proxy server is configured, it will
attempt to tunnel Java RMI requests
through that proxy server, one at a
time.