Java Applet 沙箱安全、本地访问与外部访问
我的（代码签名）java applet 中有一个错误“访问被拒绝 (java.net.SocketPermission xxxx:443 connect_resolve)。”我们有一个 html“保存”按钮，它正在调用（通过 javascript）一个 applet 方法来保存文件，加载到小程序中，到网络服务器上。经过一些广泛的谷歌研究，我通过将小程序的保存方法代码包装在 doPrivileged() 中来修复它。错误似乎已修复，
我想确认我完全理解原始内容 。环境和我应用的解决方案（我知道，但是周转时间不允许我真正研究这个问题，
特别让我困惑的是我们在内部网络的测试服务器上广泛测试了我们的小程序 ）。直到我们尝试从网络外部的客户端计算机上使用 javascript“保存”按钮时，才出现此错误。所以此时，我只是做出一个有根据的猜测：这就是 java applet 沙箱机制的工作原理，
这是真的吗？只要客户端小程序从位于同一域网络内的客户端计算机访问 Web 服务器资源，就被视为在沙箱墙内？如果客户端计算机位于 Web 服务器本地网络的外部，则小程序请求将被视为在沙箱墙之外并且需要 doPrivileged？或者这里还有我缺少的其他解释吗？
我无法在sun的文档中或通过google找到任何具体证明或反驳我的断言的内容。非常感谢在 Java 小程序方面有更多经验的人的澄清
I had a bug in our (code signed) java applet "access denied (java.net.SocketPermission x.x.x.x:443 connect_resolve." We had an html "save" button that was calling (via javascript) an applet method to save a file, loaded into the applet, onto the webserver. After some extensive google research, I fixed it by wrapping our applet's save method code in doPrivileged(). Bug seems to be fixed, people are happy.
I want to confirm that I completely understand the original circumstances and the solution I applied (backwards, I know, but turn around time didn't allow me to really research the issue).
Whats specifically confusing me is that we tested our applet on a test server in our in-house network extensively and never got this error until we attempted the javascript "save" button from a client machine external to our network. So at this point, I'm just making an educated guess: that is how the java applet sandbox mechanism works.
Is this true? As long as the client applet is accessing web server resources from a client machine that is within the same domain network it is considered within the sandbox walls? And if the client machine is external to the web-server's local network the applet request is considered outside of the sandbox walls and needs the doPrivileged? Or is there another explanation here that I am missing?
I haven't been able to find anything in sun's documentation or through google that specifically proves or disproves my assertion. Clarification from someone with more experience in java applets is greatly appreciated
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的意思是沙盒小程序可以“回拨”到自己的服务器，那么是的。
小程序需要信任（数字签名+最终用户接受）才能访问其他服务器的资源。让事情变得更加复杂的是 JavaScript。突然间，JRE 需要考虑一个“不可信”元素。通过将代码包装在 doPrivileged() 方法中，我们向 JRE 表明该代码是可信的，即使被其他东西（例如 JS）调用也是如此。
If by that, you mean a sand-boxed applet can 'phone home' to its own server, then yes.
An applet needs trust (digitally signed + accepted by the end user) to access resources from other servers. The thing that further complicates it is the JavaScript. Suddenly there is an 'untrusted' element to be considered by the JRE. By wrapping the code in the doPrivileged() method we are saying to the JRE that this code is to be trusted even if called by something else such as JS.