Bugs item #3151350, was opened at 2011-01-04 19:12 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=3151350&group_id=23629
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Applet Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Andrew Dunn (adunn8) Assigned to: Bob Hanson (hansonr) Summary: Applet not loading files after Java 6 update 22 Initial Comment: We are having a problem with Jmol applet not being able to load new files via the javascript interface after the applet is instantiated. The initial file is loads fine, but when we switch to another model (see link), we get a java.security.AccessControlException. I have observed the issue only affects clients who are running Java 6 update 22 or higher. It was working fine previous to this update. Link to Jmol application (Protein Viewer): http://elsevier-apps.sciverse.com/ProteinViewer/ProteinViewer.html?pii=S0022283610004328# Steps to recreate (must have java 6 update 22 or higher installed): 1.) Access link above - Protein Viewer application will load the first structure in the film strip above (highlighted yellow) 2.) Click on any other structure in the filmstrip above the Jmol applet - The Jmol will try to load the structure's file for 10 seconds and then a custom error message will be displayed. The file has failed to load. 3.) Check java console. - You should see a stack trace similar to the one attched. 4.) If desired, uninstall java and install an update 21 or earlier to see Protein Viewer functioning correctly I have attached the Java console output. Notice that the first file (2VOA.pdb.gz) loads fine, but the second produces an error. Both use the same URI. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-01-07 17:27 Message: FYI ... we have confirmed its a network issue. It seems that starting with update 22, java has modified its security policy for applets so that both a regular DNS lookup (by host) and then a reverse DNS lookup (by IP) are executed on http requests. For what ever reason, we don't have a reverse entry in our DNS which causes the socket permission error. I've confirmed this by modifying my local host file to proxy all requests to apps-elsevier.sciverse.com and everything works. Now its a matter of getting the DNS entries made. I guess from my perspective, you can go ahead and close this ticket. Thanks so much for your responsiveness and helping us out. Give my regards to the rest of your team as well. What you guys do here is really appreciated. Jmol is a great product. Keep up the good work! ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2011-01-06 01:01 Message: And IP address lookup for elsevier-apps.sciverse.com gives 198.185.19.113, but that address does not work in http://198.185.19.113. DId you recently establish this domain name? If you know your real IP address, try using that instead of the name so no name look-up is required. ---------------------------------------------------------------------- Comment By: Andrew Dunn (adunn8) Date: 2011-01-05 23:51 Message: Think I found something which may explain the issue with java version. This is from the update 22 release notes: "The fix for CVE-2010-3560 could cause certain Java applets running in the new Java Plug-in to stop working if they are embedded in web pages which contain JavaScript that calls into Java in order to perform actions which require network security permissions. These applets may fail with a network security exception under some circumstances if the name service which resolved the original web page URL host name does not return a matching name as the result of a reverse address lookup. This is most likely to occur for the new Java Plug-in running on Solaris and Linux when configured to use NIS for host to network address resolution with maps containing host names which are in short form (rather than as a fully qualified domain name). If an applet is suspected of failing due to this change you can verify that by setting the logging level of the Java Console to 5 and looking for logging strings beginning with "socket access restriction" ...." http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html Certainly sounds similar to the issue I'm facing, although I'm not seeing the "socket access restriction" message. Perhaps this is a related issue. ---------------------------------------------------------------------- Comment By: Andrew Dunn (adunn8) Date: 2011-01-05 20:05 Message: I set up Apache's TCPMon (http://ws.apache.org/commons/tcpmon/tcpmontutorial.html) to monitor the http request/response traffic on my machine when using Protein Viewer. When I get the AccessControlException it doesn't look like the proxy request is even being made, and I've confirmed that the server isn't receiving the request either. ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2011-01-05 00:38 Message: OK, I've pinned the problem down to your server. I don't know what it is, but something about that ProxyServlet call is what is doing it. This will fail: http://chemapps.stolaf.edu/jmol/docs/examples-12/t2.htm It calls your site using your JAR file and reads the first file, but then, as you say, the "test" link there fails to read that same file again. Here is the same thing, using St. Olaf site: http://chemapps.stolaf.edu/jmol/docs/examples-12/t2.htm?STOLAF Now clicking on "test" works. The only difference is the site -- yours versus mine. So I'm guessing it does not have to do with Java version 22 (I'm using 23 here). You must have also done something different in relation to that proxy server. ---------------------------------------------------------------------- Comment By: Andrew Dunn (adunn8) Date: 2011-01-04 22:12 Message: Thanks for the quick response, Bob. We are proxying the files from pdb.org, so they don't physically exist on our server. Sort of like the technique used by First Glance out lined here: http://molvis.sdsc.edu/fgij/datameth.htm . We don't use apache re-write, but a servlet that repackages the response, so it should appear to be coming from our server. It has worked up until the latest java updates came out. We were originally thinking it had something to do with the network plumbing, but we came to find that the file request was not even making it to server, like it was stuck on the client. What makes it even weirder is the fact that we can load the first model (on jmol initialization), no problem. Its only when we try to change the model. I will try your directory suggestion to see, if that changes anything. ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2011-01-04 21:39 Message: I've tested this now at http://chemapps.stolaf.edu/jmol/docs/examples-11/new.htm I think it's some sort of a proxy setting you might have on your server, because this is not a problem here, and I am having the problem at your server. So for example, at this site you can use javascript:jmolScript("load ../../data/1crn.pdb") That is, loading a file from a parallel set of directories from where JmolApplet.jar is found. That's the proper behavior. So what is different about your server? Do you by any chance have some sort of settings that would give a different IP address domain for the HTML file than for the loading file? It's got to be something like that. Bob ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2011-01-04 21:22 Message: Right, so there appears to be a new security model there. It seems to me we know about this... I'll have to do some looking. But the solution should be to move JmolApplet.jar (or JmolApplet*.jar) to the directory containing or above the directory containing the PDB files. Or switch to the signed applet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=3151350&group_id=23629 ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Jmol-developers mailing list Jmol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-developers
