Java：安全异常 - 非法 url 重定向答案

【问题标题】：Java: Security Exception - illegal url redirectJava：安全异常 - 非法 url 重定向
【发布时间】：2012-09-29 00:10:57
【问题描述】：

有没有人遇到过这种情况？这给我的小程序工作带来了很多麻烦。我认为它不起作用的原因是由于我的程序中的套接字与服务器通信。但是，我不知道如何阻止它，谷歌也没有帮助。我无法获得异常，因为 google chrome 的 java 控制台没有输出错误，只是在单击错误小程序说它出错后才给我一个弹出窗口。如果需要代码，我会添加。提前谢谢。

security:  --- parseCommandLine converted : -Djava.net.preferIPv4Stack=true
into:
[-Djava.net.preferIPv4Stack=true]
basic: Added progress listener: sun.plugin.util.ProgressMonitorAdapter@acf892
basic: Plugin2ClassLoader.addURL parent called for http://voidchar.com/Other/DatRLTest.jar
basic: Plugin2ClassLoader.addURL parent called for http://voidchar.com/Other/SharedClasses.jar
security: Blacklist revocation check is enabled
security: Trusted libraries list check is enabled
network: Cache entry found [url: http://voidchar.com/Other/DatRLTest.jar, version: null] prevalidated=false/0
cache: Resource http://voidchar.com/Other/DatRLTest.jar has expired.
network: Connecting http://voidchar.com/Other/DatRLTest.jar.pack.gz with proxy=DIRECT
network: Connecting http://voidchar.com:80/ with proxy=DIRECT
basic: exception: illegal URL redirect.
java.lang.SecurityException: illegal URL redirect
at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.DeployCacheHandler.get(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.downloadJAR(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.access$000(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Ignored exception: java.lang.SecurityException: illegal URL redirect
basic: Dialog type is not candidate for embedding
basic: Removed progress listener: sun.plugin.util.ProgressMonitorAdapter@acf892
basic: Loading Java Applet Failed...
security: Accessing keys and certificate in Mozilla user profile: null
security: Reset deny session certificate store

编辑：这是我用来加载小程序的 html 代码。


    {applet width=800 height=800 archive='DatRLTest.jar,SharedClasses.jar'    code='vc.voidwhisperer.datrl.main'}
    {PARAM name="java_arguments" value="-Djava.net.preferIPv4Stack=true"}
    {/applet}

小于号和大于号被替换了，因为它不喜欢我试图把东西放在他们身上。

编辑#2：我已经对 jar 进行了自签名，这仍在发生。我还没有弄清楚如何解决这个问题..

最终编辑：经过几个小时的工作，我终于找到了一个解决方案，感谢 irc 频道中的一位朋友。以下是如何修复它的一般要点：

如果您查看输出的特定行：network: Connecting http://voidchar.com/Other/DatRLTest.jar.pack.gz with proxy=DIRECT。
在查找该文件时它不存在。
对文件类型进行一些研究，它是一个 pack200 jar，可以使用 jar 制作，然后使用它执行以下操作：打开 cmd，然后输入“pack200 example.jar.pack.gz [JarLocation]”。
现在，将 example.jar 替换为您的 jar 文件的名称，但将 .pack.gz 保留在那里。
现在，将该文件上传到与小程序相同的目录并尝试再次加载小程序。

注意：确保小程序已签名！希望这有助于其他人解决我遇到的问题。

【问题讨论】：

当客户端更新到 java 7 时，我在ol-in-berlin.de/gadget/reitti.jar 遇到了同样的问题。在客户端禁用 Java 下一代插件是第一个（坏的）解决方案。幸运的是，我找到了你的这篇文章并提供了 .pack.gz 文件。谢谢分享。（也许您应该将其发布为自我回答）现在，如果有人可以提供详细的解释，为什么会发生这种情况，那就太好了。

标签： java security exception applet

【解决方案1】：

您的小程序违反了“同源”限制，这是默认的小程序安全限制，旨在保护用户免受恶意小程序的侵害。

请参阅this blog post 了解有关限制的说明以及强制执行的原因。

你能做些什么呢？最好的办法是重新设计您的小程序和/或服务，以便完全删除重定向，或者重定向到不违反限制的 URL。如果这不是一个选项，您将需要使您的小程序成为“受信任的小程序”；例如请参阅this tutorial 以了解问题。

更新

将小程序设为受信任小程序是错误的。它不会有帮助。我查看了 OpenJDK 源代码（here 和 here），似乎无论安全策略如何，都会执行“同源”安全检查。（寻找与该消息一起引发异常的代码......）

因此，您唯一的选择是从与链接到它的网页相同的主机和端口为小程序提供服务。换句话说，不要违反“同源”规则。

【讨论】：

我对小程序进行了自签名。它仍然不会加载。并且所有类都与试图加载它的页面位于同一台服务器上。我在原始帖子中添加了我正在使用的 html 代码。
唯一可能导致此问题的远程原因是我的小程序通过套接字连接到远程 ip……而我无法解决这个问题？我很确定它试图访问的两个 .jar 文件都在同一个网络服务器上，除非它试图从目录中的其他地方访问它
有什么简单的方法来诊断错误来自哪一行，因为查看堆栈跟踪，它并没有说明异常来自哪里，因此弄清楚它有点麻烦错误究竟来自哪里。
您可能在堆栈跟踪中看不到源代码行号，因为您的 JRE 的“rt.jar”文件是在没有调试信息的情况下构建的。但是，如果您查看源代码，很明显在该类中只有一个地方可以抛出异常。

【解决方案2】：

就我的研究而言，每当 java 请求小程序并获得 HTTP 300 响应时，都会导致此问题。首先java将尝试加载applet的压缩版本，例如“你的jarfile.jar.pack.gz”。如果服务器提供 HTTP 404，一切都按预期工作。但是如果服务器发送一个 HTTP 300 响应，java 会假设有一个重定向目标，如果没有设置则失败。

根据我的经验，您可以执行以下操作来解决服务器端的问题：

如果您的小程序由单个 jar 文件组成并且之后没有加载数据，您可以使用 pack200 工具压缩您的小程序并用新文件替换原始 jar。确保将 .pack.gz 文件扩展名附加到原始文件。
如果您有 apache 并完全控制您的服务器，您可以卸载 mod_speling。确保这对于您正在运行的其他环境来说没问题。
如果您可以使用 .htaccess 文件，您可以禁用加载小程序的文件夹的拼写检查。为此，创建一个内容为“CheckSpelling off”的 .htaccess 文件。如果已经存在 .htaccess 文件，只需添加这一行即可。

我希望这可以帮助一些人。

【讨论】：

【解决方案3】：

您很可能违反了您的 java 小程序环境的沙盒策略。无论您想做什么，您都没有所需的凭据，并且您没有询问用户是否可以，因此环境杀死了您。

http://docs.oracle.com/javase/tutorial/security/tour1/step1.html

【讨论】：

我添加了我终于弹出的异常。

【解决方案4】：

我在使用 Java 1.7.0_09 时在客户的服务器上看到了同样的问题。如果我使用早期版本的 Java 则没有问题。如果我在不同的服务器上运行相同的 Applet，那就没问题了。

我终于找到了解决办法。我清除了我的 Java 缓存。（这与浏览器缓存不同。）

在 Windows 7 上，您可以：

启动 Java 控制面板，
点击“常规”标签，
在“Internet 临时文件”下单击“设置”，
点击“删除文件”，
仅选择“缓存的应用程序和小程序”并点击确定。

清除我的 Java 缓存花了将近一分钟。

然后一切正常。

【讨论】：