 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Security / March 2007interesting applet security problem
I've got a Java applet that talks to a back-end server. The applet has a "Start" button that causes it to establish the connection. The back-end server is NOT the web server that the HTML web page containing the applet comes from, so the applet JAR file is stored on the back-end server, and the HTML code references the JAR file by an absolute URL with that back-end server as the host. That works fine. Now we want to replace the GUI presented by the applet with one implemented in Javascript. The applet itself becomes faceless (applet tag has width=0 and height=0). The JavaScript calls a method in the applet to do what the "Start" button did before. That works fine, *if* the web page and applet are on the same server. It fails if they are not. I spent some time trying to figure out why. As near as I can tell, the problem is that when the JavaScript running in the browser makes a method call into the applet, even though it is calling the same method the Start button did, it is calling it from a different thread. The Start button is called in a thread that toString reports as "Thread[AWT-EventQueue-4,4,<html-page-url>/-threadGroup]". The method called by Javascript is in a thread that toString reports as "Thread[Thread-2,5,main]". Are there really different security policies in place in the applet based on which thread is running? Thanks! Eric > I've got a Java applet that talks to a back-end server. .. > The method called by Javascript .. ..as far as I vaguely recall, some OS components (read IE) will put applets called by JS into a special category. The JS needs to be trusted, or something like that.. What is the end purpose of calling the applet using JS? Andrew T. > What is the end purpose of calling the applet > using JS? Our web developers need to customize the look and feel for OEMs, but don't do Java programming. I do Java programming, but am not very good at graphic design. By using JavaScript to implement the UI, I am removed from the web development bottleneck. Eric >> What is the end purpose of calling the applet >> using JS? [quoted text clipped - 3 lines] > good at graphic design. By using JavaScript to implement the UI, > I am removed from the web development bottleneck. It is extremely short-sighted to make an architecture decision based on the putative skill of a current team member. Architecture decisions should be based on engineering principles. Javascript has issues as the primary front-end tool - it is harder to lock down exceptions and types, it bloats the client and browsers can have JS disabled for a variety of reasons, As you discovered, it is also tricky to manage the sandbox interactions. When one doesn't use an applet for the GUI, why is it necessary to use an applet? Why not set up a Web app with server-side logic? Has anyone considered the long-term effects on maintainability of your architecture? -- Lew > It is extremely short-sighted to make an architecture decision based > on the putative skill of a current team member. Web designers with JavaScript experience seem to be easier to find than Java engineers. The user interface of the applet is really a web design issue rather than an engineering issue, so it make sense to do it using tools with which web designers are skilled. > Architecture decisions should be based on engineering principles. I don't think I've violated any engineering principles. > Javascript has issues as the primary front-end tool - it is harder to > lock down exceptions and types, it bloats the client The UI is very simple, so none of this seems to be an issue in this case. > and browsers can have JS disabled for a variety of reasons, And browsers can have Java disabled for a variety of reasons. If the end user wants to run our applet, he or she will enable both Java and JavaScript. A Java developer criticizing JavaScript for issues of deployability seems ridiculous to me; it is much easier and faster for an end user to enable JavaScript than to install the JRE and enable Java. > As you discovered, it is also tricky to manage the sandbox interactions. True. > When one doesn't use an applet for the GUI, why is it necessary to use > an applet? Why not set up a Web app with server-side logic? Because the purpose of the applet is to measure aspects of network performance. That can't be done on the server side without client side code. > Has anyone considered the long-term effects on maintainability of your > architecture? Yes. It replaces an older configuration in which the client side was an ActiveX control written in Delphi (as was the server end). That meant that it was only available to end users running Internet Explorer. It was also much harder to find developers skilled in Delphi. Eric > -- cogent answers -- That is very enlightening, thank you. It is educational to see the legitimate uses for Javascript and the JS/Java interactions as you describe them. It is perhaps more so to see the considerations of talent costs and availability that you described. My lesson is that there is no single "best" solution for all situations, but that the human and unique technical needs of each situation demand wholistic attention. I appreciate your considered response; because of it doors have opened in my mind. -- Lew > > -- cogent answers -- > That is very enlightening, thank you. My pleasure. Thank you for raising the issues, as it made me think about the system architecture in more depth than I had done previously. Eric > The back-end server is NOT the web server that the HTML web page > containing the applet comes from, so the applet JAR file is stored on > the back-end server, and the HTML code references the JAR file by > an absolute URL with that back-end server as the host. Applets downloaded from different hosts cannot talk to each other. Likewise, applets downloaded from a different host to the web page they are on, cannot communicate with the JavaScript from the other host. So, either put everything for the page on one host, or use port forwarding (through your router, if your server supports it something like ipfw/ipchains/iptables or a small forwarding server). Tom Hawtin > Applets downloaded from different hosts cannot talk to each > other. Probably true, I'll get back to that. > Likewise, applets downloaded from a different host to the web > page they are on, cannot communicate with the JavaScript from the > other host. Yesterday I proved that false. I was able to make my test work by having the Javascript (from host 1) call into the applet (from host 2), then use InvokeLetter to make the desired function execute with the applet's security policy. By this method, the Javascript from host 1 can make the applet do basically anything the applet is allowed to do, including network access to the host the applet was loaded from. The Java applet has no trouble calling the Javascript (provided MAYSCRIPT is true). No special security considerations were required in that direction. I am unsure whether the ability for JavaScript from host 1 to invoke arbitrary public methods in the applet from host 2 is a security problem; I haven't yet thought up with any serious threats that it would enable. On the other hand, this ability is crucial to my project, so I'm glad it works. Perhaps the InvokeLater approach might allow applets loaded from different hosts (by the same HTML page) to interact, though I have not tried this. If not directly, one applet could (if MAYSCRIPT is true) invoke JavaScript on the HTML page that could in turn invoke public methods of the other applet. > So, either put everything for the page on one host, or use port > forwarding (through your router, if your server supports it something > like ipfw/ipchains/iptables or a small forwarding server). We can't easily do that, because the applet MUST reside on a host with very high internet bandwidth available (for the back end that the applet communicates with), while the HTML page MUST be able to reside on a host not of our own choosing. The web server for the HTML page cannot be in the data path between the applet and the back end server. In principle, the JavaScript code could be served up by the back end server where the applet resides, if that was needed to enable the JavaScript and Java applet to interact. However, I suspect that the security policies are based on where the HTML came from, not where separately included JavaScript came from. Eric Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.