javascript Java Applet 连接我们的服务器以调用 PHP 文件的问题
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4989120/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Problem with Java Applet to connect our server to call a PHP file
提问by Muthu Kumaran
We are facing a problem with lastest JRE 6 update 22 and 23. The problem is we are running a site which uses Java Applet to stores/retrieve datas by calling a PHP file. For last 7 years we never had a single issue but now with latest JRE are we having a problem. The Java applet is loaded fine but failed to connect our sever (unix server) which suppose to call the PHP file.
我们面临最新的 JRE 6 更新 22 和 23 的问题。问题是我们正在运行一个站点，该站点使用 Java Applet 通过调用 PHP 文件来存储/检索数据。在过去的 7 年里，我们从未遇到过任何问题，但现在使用最新的 JRE，我们遇到了问题。Java 小程序加载正常，但无法连接我们的服务器（unix 服务器），它假设调用 PHP 文件。
Note: We use Javascript to call a Java function to connect our server, to retrieve data from the PHP file.
注意：我们使用 Javascript 调用 Java 函数来连接我们的服务器，从 PHP 文件中检索数据。
Here is the error message found in Java console:
这是在 Java 控制台中发现的错误消息：
basic: Applet started
basic: Told clients applet is started
Retreiving cmi for sco=778 from ATutor server
network: Connecting http://www.example.com/training/scorm/read.php with proxy=DIRECT
network: Cache entry not found [url: http://xxx.xxx.xxx.xxx/crossdomain.xml, version: null]
network: Connecting http://xxx.xxx.xxx.xxx/crossdomain.xml with proxy=DIRECT
network: Connecting http://xxx.xxx.xxx.xxx:80/ with proxy=DIRECT
network: Server http://xxx.xxx.xxx.xxx/crossdomain.xml requesting to set-cookie with "SESSdba781ab68368f3b7b29ce28e33a2679=983ded5e21e40047871b1f3ce5c259d7; expires=Monday, 07-Mar-11 20:45:53 GMT; path=/"
ATutor cmi retrieval failed.
java.security.AccessControlException: access denied (java.net.SocketPermission xxx.xxx.xxx.xxx:80 connect,resolve)
Oracle has released a note and addressing this issue with a solution, Website: http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html
Oracle 已发布说明并通过解决方案解决此问题，网址：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. 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" which will describe the specific cause of the mismatch and will help in identifying the correct workaround to use as described below:
Add a new host name forward map entry (in /etc/hosts, NIS, or DNS) in a special form which is recognized by Java for the purpose of validating IPv4 and IPv6 name service mappings. The IPv4 general name form followed by an /etc/hosts file fragment example for IP address 10.11.12.13 is:
host.auth.ddd.ccc.bbb.aaa.in-addr.arpa # /etc/hosts example 10.11.12.13 foo.bar.com.auth.13.12.11.10.in-addr.arpaThere is an equivalent form for IPv6 addresses which uses the IP6.ARPA domain root format defined in RFC 3596.
For DNS, these would be A (IPv4) or AAAA (IPv6) entries.
Pre-pend a fully qualified host name before other mappings to the same address. For example, in /etc/hosts format:
#10.11.12.13 foo loghost 10.11.12.13 foo.bar.com foo loghostAs an alternative to updating name service records, it may be possible to safely modify the applet to perform the network action using only it's own permissions independent of the web page which contains it by using the doPrivileged() method of the java.security.AccessController class.
如果 CVE-2010-3560 的修复程序嵌入在包含调用 Java 以执行需要网络安全权限的操作的 JavaScript 的网页中，则可能导致在新 Java 插件中运行的某些 Java 小程序停止工作。在某些情况下，如果解析原始网页 URL 主机名的名称服务没有返回匹配的名称作为反向地址查找的结果，则这些小程序可能会因网络安全异常而失败。对于在 Solaris 和 Linux 上运行的新 Java 插件，当配置为使用 NIS 进行主机到网络地址解析以及包含短格式主机名（而不是完全限定域名）的映射时，最有可能发生这种情况。
如果怀疑小程序由于此更改而失败，您可以通过将 Java 控制台的日志记录级别设置为 5 并查找以“套接字访问限制”开头的日志记录字符串来验证这一点，该字符串将描述不匹配的具体原因并提供帮助确定要使用的正确解决方法，如下所述：
以 Java 可识别的特殊形式添加新的主机名转发映射条目（在 /etc/hosts、NIS 或 DNS 中），以验证 IPv4 和 IPv6 名称服务映射。IPv4 通用名称格式后跟 IP 地址 10.11.12.13 的 /etc/hosts 文件片段示例是：
host.auth.ddd.ccc.bbb.aaa.in-addr.arpa # /etc/hosts example 10.11.12.13 foo.bar.com.auth.13.12.11.10.in-addr.arpaIPv6 地址有一种等效形式，它使用 RFC 3596 中定义的 IP6.ARPA 域根格式。
对于 DNS，这些将是 A (IPv4) 或 AAAA (IPv6) 条目。
在到同一地址的其他映射之前预先添加一个完全限定的主机名。例如，在 /etc/hosts 格式中：
#10.11.12.13 foo loghost 10.11.12.13 foo.bar.com foo loghost作为更新名称服务记录的替代方法，可以使用 java.security.AccessController 的 doPrivileged() 方法安全地修改小程序以仅使用它自己的权限来执行网络操作，而独立于包含它的网页班级。
I am PHP developer and I have very little knowledge on Java. I couldn't understand the solution provided by the Oracle. They want to add new host name in /etc/hosts file, can anyone please explain with more clear example what to add in /etc/hosts.
我是 PHP 开发人员，对 Java 知之甚少。我无法理解 Oracle 提供的解决方案。他们想在 /etc/hosts 文件中添加新的主机名，任何人都可以用更清楚的例子解释在 /etc/hosts 中添加什么。
Also I don't know where to add doPrivileged() method, please help.
另外我不知道在哪里添加 doPrivileged() 方法，请帮忙。
Thanks
谢谢
回答by Pa?lo Ebermann
Java applets are only allowed to call their own origin host, and it seems that from the change mentioned by your citation above that Javascript code calling into the applet has no networking rights at all, to avoid that hostile scripts use your applet to connect to your server with the privileges of the applet instead of its own.
Java applet 只允许调用它们自己的原始主机，从上面引用的变化来看，调用 applet 的 Javascript 代码根本没有网络权限，以避免恶意脚本使用您的 applet 连接到您的服务器具有小程序的权限而不是它自己的权限。
If you are sure that no malicious things could happen if your applet method is called(even if called by a malicious script), you can use in this method this call to AccessController.doPrivileged(...), like this:
如果您确定调用您的小程序方法不会发生恶意事件（即使被恶意脚本调用），您可以在此方法中使用此对 AccessController.doPrivileged(...) 的调用，如下所示：
public String retrieveData(final String params) {
return AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
// here the rest of your networking code
}
};
}
Instead of wrapping the whole method in doPrivileged, maybe only wrap the networking parts (like openConnection() or such).
与其将整个方法包装在 doPrivileged 中，不如只包装网络部分（如 openConnection() 等）。
回答by Muthu Kumaran
Pa?lo,
帕洛，
Server admin uploaded a crossdomain.xml file to the root web directory of the site that resolve the public ip. This is the only information I received.
服务器管理员将 crossdomain.xml 文件上传到解析公共 ip 的站点的 web 根目录。这是我收到的唯一信息。
Here is the crossdomain.xmlfile,
这是crossdomain.xml文件，
<?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>
This fixed the problem and no errors appears in Java console logs.
这解决了问题，Java 控制台日志中没有出现错误。
These errors are fixed,
这些错误已修复，
network: Cache entry not found [url: http://xxx.xxx.xxx.xxx/crossdomain.xml, version: null]
java.security.AccessControlException: access denied (java.net.SocketPermission xxx.xxx.xxx.xxx:80 connect,resolve)
