访问被拒绝（java.net.SocketPermission 127.0.0.1:8080 连接，解决）

access denied (java.net.SocketPermission 127.0.0.1:8080 connect,resolve)

提问by PropellerHead

I have a Java Applet inserted on a simple HTML page located at http://localhost:8080/index.html:

我在位于http://localhost:8080/index.html的简单 HTML 页面上插入了一个 Java Applet ：

<applet id="applet" code="SomeCode.class" archive="lib.jar" Width="1" Height="1"></applet>

The Java Applet has a method that looks similar to the code below:

Java Applet 有一个类似于以下代码的方法：

public void PostStuffToServer() {
  String server = "http://localhost:8080/PostHandler.ashx";
  URL u = new URL(server);
  URLConnection con = u.openConnection();
  con.setDoOutput(true);
  con.getOutputStream().write(stream.toByteArray());
  con.connect();
}

When I execute the applet code from JavaScript like so:

当我像这样从 JavaScript 执行小程序代码时：

obj = document.getElementById('applet');
obj.getClipboardImageURL();

I get the following error:

我收到以下错误：

access denied (java.net.SocketPermission 127.0.0.1:8080 connect,resolve)

访问被拒绝（java.net.SocketPermission 127.0.0.1:8080 连接，解决）

It seems like the Java code resolves the domain localhostto its equivalent IP address and therefore raises a cross domain security restrain. It works fine when I execute the same code from http://127.0.0.1:8080/index.html. The lib.jar file is signed.

似乎 Java 代码将域localhost解析为其等效的 IP 地址，因此引发了跨域安全限制。当我从http://127.0.0.1:8080/index.html执行相同的代码时，它工作正常。lib.jar 文件已签名。

Is there anyway to avoid this?

有没有办法避免这种情况？

采纳答案by Kristian

I encountered the same problem after installing Java 6 Update 22. My applet has been online for several years with no reported errors. When I downgrade to version 6 Update 21, everything works perfect. My applet is not signed.

我在安装 Java 6 Update 22 后遇到了同样的问题。我的小程序已经上线几年了，没有报告错误。当我降级到版本 6 Update 21 时，一切正常。我的小程序没有签名。

SOLUTION: It took me ha while to find the cause of the problem. Actually in my case there were several factors causing the security error. The problem was solved by the crossdomain.xml file. The Java applet tried to download the crossdomain file, failed, and did not even bother to display an error in the java console (debug level 5). Java tried to download the file from the ip adress of my domain (http://ip-address/crossdomain.xml), and not the root of my website (http://domain-name/crossdomain.xml). I guess it is better for the security aspect? I then had to configure the webserver to expose the crossdomainfile on the IP address. In my case I have removed the default website in ISS for security reasons, and had to create a new website. I then discovered that the java applet did not work with the crossdomain files i use with flash:

解决方案：我花了一段时间才找到问题的原因。实际上，就我而言，有几个因素导致了安全错误。该问题已通过 crossdomain.xml 文件解决。Java 小程序尝试下载跨域文件，失败，甚至懒得在 Java 控制台中显示错误（调试级别 5）。Java 试图从我的域的 ip 地址 (http://ip-address/crossdomain.xml) 下载文件，而不是我网站的根目录 (http://domain-name/crossdomain.xml)。我想这对安全方面更好吗？然后我必须配置网络服务器以在 IP 地址上公开跨域文件。就我而言，出于安全原因，我删除了 ISS 中的默认网站，并且不得不创建一个新网站。然后我发现 java 小程序不能与我与 flash 一起使用的跨域文件一起使用：

<?xml version="1.0"?>
<cross-domain-policy>
   <site-control permitted-cross-domain-policies="master-only"/>
   <allow-http-request-headers-from domain="*" headers="*"/>
   <allow-access-from domain="*" />
</cross-domain-policy>

I had to remove the site-control and allow-http-request-headers-from nodes from the xml file in order to make the applet work.

我必须从 xml 文件中删除 site-control 和 allow-http-request-headers-from 节点才能使小程序工作。

回答by Tom Hawtin - tackline

IIRC, the JavaScript same-origin policy prevents access to same-host/different-port. The PlugIn's LiveConnect enforces this policy for localhost only.

IIRC，JavaScript 同源策略阻止访问相同主机/不同端口。插件的 LiveConnect 仅对本地主机强制执行此策略。

回答by Edmund Edgar

I'm getting the same thing with Update 22, and not Update 21.

我在更新 22 中得到了同样的结果，而不是更新 21。

I'm using the TinyPlayerapplet, which I'm controlling via JavaScript.

我正在使用TinyPlayer小程序，我通过 JavaScript 控制它。

I'm loading audio files from the same domain (mydomain.example.com, IP 1.2.3.4) as the page the applet is loading on - everything is referenced using relative URLs.

我正在从与小程序加载页面相同的域（mydomain.example.com，IP 1.2.3.4）加载音频文件 - 所有内容都使用相对 URL 进行引用。

When I try to play the audio, it fails to play and I get: access denied (java.net.SocketPermission 1.2.3.4:80 connect,resolve)

当我尝试播放音频时，它无法播放，我得到：访问被拒绝（java.net.SocketPermission 1.2.3.4:80 connect,resolve）

Looking at the access logs, I get a request for crossdomain.xml right before this happens. But the catch is that Java isn't asking for a crossdomain.xml from mydomain.example.com/crossdomain.xml ...but instead from 1.2.3.4/crossdomain.xml

查看访问日志，我在发生这种情况之前收到了对 crossdomain.xml 的请求。但问题是 Java 不是从 mydomain.example.com/crossdomain.xml 中请求 crossdomain.xml ...而是从 1.2.3.4/crossdomain.xml

The workaround that seems to work for me is to set up a virtual host that responds for the IP address 1.2.3.4, and give it a crossdomain.xml, so that Java can find the crossdomain.xml in the (wrong) place that it's looking for it.

似乎对我有用的解决方法是设置一个响应 IP 地址 1.2.3.4 的虚拟主机，并为其提供一个 crossdomain.xml，以便 Java 可以在它所在的（错误）位置找到 crossdomain.xml寻找它。

I just tested with the contents:

我刚刚测试了内容：

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

...but it's probably possible to make this more restrictive.

...但有可能使其更具限制性。

With that in there, the audio plays correctly.

有了它，音频就可以正确播放了。

回答by Edmund Edgar

Just to add, there's some stuff here which exactly matches the issue I've been getting - it specifically mentions controlling an applet with JavaScript.

补充一点，这里有一些内容与我遇到的问题完全匹配 - 它特别提到了使用 JavaScript 控制小程序。

http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html

http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html

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.

如果 CVE-2010-3560 的修复程序嵌入在包含调用 Java 以执行需要网络安全权限的操作的 JavaScript 的网页中，则可能导致在新 Java 插件中运行的某些 Java 小程序停止工作。在某些情况下，如果解析原始网页 URL 主机名的名称服务没有返回匹配的名称作为反向地址查找的结果，则这些小程序可能会因网络安全异常而失败。

Their suggestion is to add a special crazy just-for-Java A record to the DNS, like:

他们的建议是在 DNS 中添加一个特殊的疯狂的 Java A 记录，例如：

10.11.12.13    foo.bar.com.auth.13.12.11.10.in-addr.arpa

10.11.12.13    foo.bar.com.auth.13.12.11.10.in-addr.arpa

回答by José

I don't think is possible to made the crossdomain.xml file more restrictive, at current time Java applets only support the (domain="*")

我认为不可能使 crossdomain.xml 文件更具限制性，目前 Java 小程序仅支持 (domain="*")

see here http://www.oracle.com/technetwork/java/javase/index-135519.html#CROSSDOMAINXML

见这里http://www.oracle.com/technetwork/java/javase/index-135519.html#CROSSDOMAINXML

回答by Sandy

You should check your virtual directory permissions.

您应该检查您的虚拟目录权限。

回答by Daniel Voina

See: http://download.oracle.com/javase/tutorial/deployment/applet/security.html

请参阅：http: //download.oracle.com/javase/tutorial/deployment/applet/security.html

Unsigned applets can perform the following operations:

未签名的小程序可以执行以下操作：

They can make network connections to the host they came from.

他们可以与他们来自的主机建立网络连接。

If Java does not resolve the originating system to localhost then the applet will not be able to open sockets.

如果 Java 未将原始系统解析为 localhost，则小程序将无法打开套接字。

回答by cxxchamp

I think I'm too late, but anyways... Guys you cannot believe how easy a solution this problem has.

我想我为时已晚，但无论如何......伙计们，你们无法相信这个问题有多么容易解决。

The problem is that Java applet code called from JavaScript has only permissions that are the intersection of the JavaScript's code and your applet code - and somehow the JavaScript's permissions are seen as less, which results in this Exception.

问题是从 JavaScript 调用的 Java applet 代码只有 JavaScript 代码和您的 applet 代码交集的权限 - 不知何故，JavaScript 的权限被视为较少，从而导致此异常。

Here is what I did: assume you have a function innocentFunc()that throws the java.net.SocketPermission exception, so your code is something like so:

这是我所做的：假设你有一个innocentFunc()抛出 java.net.SocketPermission 异常的函数，所以你的代码是这样的：

String s = innocentFunc();

Now what you can do is to change it to something like so:

现在您可以做的是将其更改为如下所示：

String s = AccessController.doPrivileged(
      new PrivilegedAction<String>() {
          public String run() {
              return innocentFunc();
          }
        }
     );

This AccessController call basically states to the Java Virtual Machine that the code it runs should not obey to the permissions from the call chain, but rather only the caller's permissions in its own.

这个 AccessController 调用基本上向 Java 虚拟机声明它运行的代码不应服从调用链中的权限，而应该只服从调用者自身的权限。

Of course, you should do something like this only after making sure that this innocentFunccall can't do anything bad, even if invoked by malicious code.

当然，只有在确保此innocentFunc调用不会做任何坏事之后，您才应该这样做，即使被恶意代码调用。

回答by Jae Song

I had the similar issue and it only occurs when I use the "localhost" as a part of the URL for the page with the applet. When I used the URL with the actual host name or IP address as a part of the URL, the problem didn't happen. I am not sure this is a defect for the Java plug-in...

我遇到了类似的问题，只有当我使用“localhost”作为带有小程序的页面的 URL 的一部分时才会发生。当我使用带有实际主机名或 IP 地址的 URL 作为 URL 的一部分时，问题没有发生。我不确定这是 Java 插件的缺陷...

For example when I used the URL like http://localhost:9080/app_id/appletPagethe problem occurred but when I use the URL by using the actual IP or host name, the problem did not occur.

例如，当我使用像http://localhost:9080/app_id/appletPage这样的 URL 时出现问题，但是当我使用实际 IP 或主机名使用 URL 时，问题没有发生。

回答by MrLymy

Update from @Kristian above saved my day.

上面@Kristian 的更新拯救了我的一天。

I had access denied (java.net.SocketPermission <server_ip>:<server port> connect,resolve)from an applet in a web application.

我access denied (java.net.SocketPermission <server_ip>:<server port> connect,resolve)从 Web 应用程序中的小程序中获得。

There had been change in our DNS, such that the IP of the load-balancer of the application server was not resolving to a name with domain. Therefore the suspected "cross-domain connection" from applet back to server was blocked. I added crossdomain.xml with

我们的 DNS 发生了变化，因此应用服务器的负载均衡器的 IP 没有解析为带有域的名称。因此，从小程序返回服务器的可疑“跨域连接”被阻止。我添加了 crossdomain.xml

<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>

<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>

to <tomcat-home>/webappsand checked that it is accessible with http://<server name>:<server port>/crossdomain.xml

到<tomcat-home>/webapps并检查它与访问http://<server name>:<server port>/crossdomain.xml