Tag: sandbox

JSE 1.8，Sandbox Java Applet通过HTTPS加载，但是使用HTTP检索了crossdomain.xml

大家好，所有的Java / Applet专家， 我偶然发现了最新JDK版本（1.8.0_b26）的一个有趣问题。 当使用最新的JDK运行Sandbox Java Applet时，我们尝试使用不同的协议连接回服务器 – 而不是原始的HTTPS我们使用WSS（安全的Websockets连接，我们使用第三方Websockets客户端Java库）。 结果，JVM尝试从服务器检索crossdomain.xml文件。 问题是，使用HTTP（而不是HTTPS）协议检索文件。 例如，在我们的例子中，服务器IP是192.168.1.1，applet是通过HTTPS默认端口（443）加载的。 在Java控制台中使用跟踪级别5，我们看到从http://192.168.1.1:443检索了crossdomain.xml 。 当然它不起作用，因为服务器只侦听端口443（而不是HTTP）上的HTTPS连接。 另一方面，当我们使用HTTP协议并向服务器打开新的WS（不安全的Websockets连接）时，问题不会出现，因为从http://192.168.1.1:80检索到crossdomain.xml并且它完全是正确。 随着问题的进一步调查，我们进行了更多的观察： 可以使用jnlp.altCrossDomainXMLFiles Java VM参数提供crossdomain.xml文件的替代位置。 我们永远不会成功使这个参数适用于我们（在java_arguments列表和单独的applet参数中都尝试过）。 可能的原因可能是该参数应仅用于Webstart应用程序（尽管它不是专门针对规范编写的）。 建立Websockets连接时，连接堆栈跟踪如下： at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:790）at sun.net.www.http.HttpClient.parseHTTP（HttpClient.java:647）at sun.net.www.http.HttpClient.parseHTTPHeader （HttpClient.java:787）at sun.net.www.http.HttpClient.parseHTTP（HttpClient.java:647）at sun.net.www.protocol.http.HttpURLConnection.getInputStream0（HttpURLConnection.java:1534）at sun。 net.www.protocol.http.HttpURLConnection.access $ 200（HttpURLConnection.java:90）at sun.net.www.protocol.http.HttpURLConnection $ 9.run（HttpURLConnection.java:1431）at sun.net.www.protocol。 http.HttpURLConnection $ 9.run（HttpURLConnection.java:1429）at java.security.AccessController.doPrivileged（Native Method）at java.security.AccessController.doPrivileged（AccessController.java:713）at sun.net.www.protocol.http .httpURLConnection.getInputStream（HttpURLConnection.java:1428）位于com.sun.deploy.net.CrossDomainXML.check（未知来源）的com.sun.deploy.net.CrossDomainXML.check（未知来源）sun.plugin2.applet。 SecurityManagerHelper.checkConne 来自sun.nio.ch.SocketChannelImpl.connect（SocketChannelImpl.java:624）的sun.plugin2.applet.AWTAppletSecurityManager.checkConnect（未知来源）的ctHelper（未知来源） 因此，我们查看了CrossDomainXML.java类的最新公开源代码（尽管从2010年开始）。 从代码中可以看出，无论原始浏览器连接是什么，从服务器检索crossdomain.xml文件时始终使用http连接。 所以问题是： 可能是JDK错误还是对crossdomain.xml严格使用HTTP是设计的？ 是否在jnlp.altCrossDomainXMLFiles applet中支持jnlp.altCrossDomainXMLFiles JVM参数？ […]

可以在沙盒中运行的Mini-OSGi（如AppEngine或WebStart）？

我非常喜欢OSGi实现的模块化bundle的概念。 我也喜欢“托管部署”服务，如Google AppEngine（用于Web应用程序）或Java WebStart（用于客户端软件）。 这两个想法似乎在概念上相互补充。 但是，OSGi标准包含一些function，使得像Felix或Equinox这样的实现无法在沙盒虚拟机（如AppEngine或Webstart）之上运行。 在这些环境中，无法直接访问文件系统，例如，这会阻止用于存储持久性捆绑状态和本机库的OSGi捆绑缓存。 现在，我没有兴趣使用本机库或具有持久的bundle状态。 是否有一些框架实现了OSGi的核心包和服务概念（理想情况是以兼容的方式使OSGi包可以按原样部署到它中），但是可以在没有包缓存的情况下工作（以及沙箱中没有的其他工具） ？ 我正在寻找类似于在AppEngine或WebStart上运行的有限版本的Felix。 当然，如果WebStart引擎和Google AppEngine刚刚提供了开箱即用的OSGi框架服务，那也很棒…… 更新： AppEngine的另一个非常有限的方面是你无法启动新的线程。 这可以防止（除其他外）异步bundle生命周期管理。 显然不是WebStart的问题。