I know the scope of this question is very large and its not appropriate to ask it here. But I don't know where to go.
I have a web application (client) + a web application (server). Both are working on tomcat on two different ports.
Now, I want the client to send and receive data to/from server using HTTPS/SSL, or in better terms, using a secured connection.
Need some guidance/clarity for this. Some questions that I have are:
Should I change some settings in TOMCAT so that my server runs on HTTPS ?
Should I make changes to client as well ?
How do I establish the connection via HTTPS ?
How do I know that data is transferred over HTTPS ?
u should state the content of the jsp page to be "contentType/https"
Related
In my J2ee based application which is deployed on Oracle Weblogic 11g AS, request comes from two Oracle HTTP Web Server. One is meant for Intranet and other is for Internet users. I want to figure out from whether request is coming from Internet web server or Intranet web server. Basis this, access of application being restricted.
Can we add some request header at Oracle HTTP Web Server side which can be check in servlet once request will reach to Application server?
Idea is that we'll add request header in both the web servers with different value. Once request will reach to application server, we'll check the value of this header and identify from which web server request is coming from. Accordingly access right will be provided to the users accessing the application from internet or intranet.
Please suggest if any other solution can meet the requirement.
You could separate the traffic using networks channel. (http://docs.oracle.com/cd/E23943_01/web.1111/e13701/network.htm)
For instance register a new HTTP channel for the WLS Managed Server and point one HTTP server to this new port.
Then you could implement a Weblogic filter the achieve the expected behavior. (http://weblogic-wonders.com/weblogic/2011/03/03/weblogic-connection-filters/)
I want to create a web application, which is divided into two part one is client and another is server.
Client:
Client part is on the shared server.
Client is the GWT Application which only use to display data (containing only ui elements and ui events).
Client application is used by server to view and present it's own data.
Server:
The server is the simple java web service (restlet).
The server is reside behind the firewall.
The server contains actual data.
There are N number of servers.
Server does not contains any view if server wants ro view data it will use the gwt client application.
Every server uses same gwt application to view it's own data.
Note :
Client does not contains any address of the server. server will send the request to view it's data.
There is no firewall inbound exception on server firewall to access server data from out side client
I need to communicate client and server through firewall, Is there any architecture or design pattern to implement this type of application?
I don't think that the firewall can bring new restrictions to a GWT application compared with other types of applications (clients).
In case you have the GWT client on one server which makes calls to a different server you might have some issues due to same origin restriction.
This can be resolved in several ways:
- your GWT application has a server-side part which calls the other servers. And your GWT client makes normal RPC / JSON calls to the GWT server side (on the same server).
- in case you want to make directly the call on the different server from your GWT client you can use JSONP or the restygwt library.
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 have created one sample chat application. In that chat application, I used JApplet and front end.
Till now I was testing my application in my desktop. It is working fine. Now I want to deploy my application over any webserver.
Now I have a few questions. Currently I am using Server socket as 8989 in my chatserver. When I was testing the application in my desktop, I used to start the server as stand alone.
What are the steps I have to follow when I deploy the application over tomcat or any other web server? Which port the client will listen?
How do I start my chat server? I am new to the socket concepts.
when you say you are hosting on the webserver, i believe that its an servlet/jsp based application , which will listen to your requests , in that case the listener will be invoked at the webserver default port either 80 / 8080 (being default). In case you want to change or check , you can go to the TOMCAT_INSTALLATION_DIR/conf/server.xml and check for tag containing the port number for weblistener, and change it to whatever value you feel like.
if thats not the case and you have your own thread which opens a socket for you , you really dont need a webserver, all you need is a host machine which will start the socket listener ( your custom) and then it will listen at the port that you have configured it to be at.
As far as I got it, you're having standalone application as a server, where you handle connections to particular port.
I think there is some confusion that should be clarified.
The very basic question is:
Why do you need your chat server to be running on the web server?
This should be clear to you prio to any later steps.
As web server is there basically to handle HTTP/S requests and that's not your case, as far as I got it. As you're probably running socket TCP/UDP communication.
For the web server however your client applet implemnentation could benefit of. If it would be referrend on a simple html page (deployed inside war) it could be simply redistributable to clients via url call in a web browser.
Maybe I'd preffer to use HTTP + JSON commununication, where you could benefit from web server usage (also on the server side) and would not need any other ports than standard ones.
Not sure if it still makes sence to answer your questions as it might be irrelevant for you, but let's see.
Answers to your questions:
Basically you need war archive (rather than jar one), as that's the one accepted by web servers. once you create it (you need to follow the correct folder/file structure inside) your app could be deployed to web server.
Which port the client will listen? Basically server is the listener here => no client port listening here.
This depends on your communication implementation decision. If still sticking with TCP/UDP one, I don't think web server would be beneficial here.
which is the best method to send a numerical value data from a javscript webpage to a web server port.. i have a server socket program running on the server and listening to port 5000.
i need to send data from a webpage to the port? which is the best method?
the scene is this.
i have a C socket program running at a web server hosted in my laptop using XAMPP.
it is listeing to a port 5000 and also i have my ip address. in the web page,
i am running a javascript and when the user presses any of the arrow keys i need a value to be sent to this port.. like up -1 , down -2 etc ...
There isn't currently any way to do this in a portable fashion. Some browsers support the WebSocket standard, which gives you some limited access to sockets, but this isn't currently available in any common browsers other than Chrome and Safari. The Flash player supports a separate XMLSocket protocol, which you can also use if the Flash plugin is available. However, neither of these protocols supports raw access to sockets -- both require some initial negotiation and packet framing.
Because your web server is running on a different port than your socket program, the Javascript in the browser is restricted from making requests directly to the socket program because of the Same Origin Policy. However, there are various ways to get around this restriction. Alex Sexton has a lengthy overview of all the different ways of doing this. However, all of those ways require that your socket program be running the http protocol also.
Socket.IO seems like a perfect fit for what you are trying to do, but you'll probably need to ditch your C program.
The only way to open a network socket connection from a web page is to use a Java or Flash app to make the binary socket connection. You could then use java script to pass the data to the app which would connect and forward it to the server.
Alternatively you could use some server side code and AJAX to proxy the connection and forward the data.
The second option doesn’t rely on any browser plug-in being installed and I think would be easier to implement. It would also be able to forward to a port that is not on the web server itself as it wouldn’t be subject to browser security restrictions.
I guess making one ajax request to required port on a server... can solve the request.