Java 小程序权限
我编写了一个基本的小程序，用户从硬盘驱动器中选择一个文件，它读取该文件的第一行并将其传递给 JavaScript 进行一些额外的预处理，然后当您单击按钮时，它会尝试上传该文件通过 HTTP POST 请求发送文件。 我找到了一个非常基本的开源小程序，用于上传我为最后一点复制和修改的文件。
但问题是，它并不完全有效。 看起来运行良好，但后来我遇到了两个与权限相关的障碍。 Java 控制台中的消息表明小程序在以下两个权限上出现访问被拒绝错误：
java.lang.RuntimePermission setFactory
java.io.FilePermission read
我觉得这很奇怪，因为我认为在使用签入的“自签名”选项构建小程序时我已经向小程序授予了权限NetBeans，然后单击以确认浏览器中的小安全弹出窗口。
另外，我自己编写的部分（读取文件并将第一行传递给 JavaScript）工作得很好。 这是一个非常清楚的指示，表明小程序能够从本地文件系统读取！ 直到我真正尝试开始上传时，问题才开始出现。 我想需要注意的一件事是，上传过程似乎在一个新线程中运行，而其余部分都在主类中运行，而不创建线程。
我对Java完全是个新手，对Java中的线程知之甚少； 我是否需要以某种方式将权限传递给这个新线程？ 或者有什么效果？ 提前致谢。
I've put together a basic applet where the user selects a file from their hard drive, it reads the first line of this file and passes that off to JavaScript for some additional preprocessing, and then when you click a button it tries to upload that file through an HTTP POST request. I found a very basic open source applet for uploading files that I copied and modified for this last bit.
The trouble is, though, it doesn't quite work. It seems like it's running fine, but then I run into two snags related to permissions. The messages in the Java Console say that the applet had access denied errors on the following two permissions:
java.lang.RuntimePermission setFactory
java.io.FilePermission read
I find this strange, because I thought I had granted permission to the applet already when I built it with the "self-signed" option checked in NetBeans, and then clicked to confirm the little security pop-up in the browser.
Also, the part that I coded myself, where it reads the file and passes the first line on to JavaScript works fine. This is a pretty clear indicator that the applet is able to read from the local file system! The trouble doesn't start until I actually try to start the upload. One thing to note, I suppose, is that the upload process seems to run in a new thread, whereas the rest of it all runs in the main class without creating threads.
I am a total novice to Java and know very little about threads in Java; do I need to pass the permissions onto this new thread somehow? Or something to that effect?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能需要向安全管理员（代码，而不是管理员）请求执行特权操作的权限。 由于各种原因，小程序能够打开本地文件通常并不是一件好事，因此它受到了相当严格的保护。
基本的关键是调用
AccessController.doPrivileged()并且有一个 很好的小教程 位于 Java Ranch FAQ 上。You probably need to ask the security manager (code, not administrator) for permission to do a privileged operation. For various reasons, it's not generally a good thing for an applet to be able to open a local file, so it's guarded pretty heavily.
The basic key is to call
AccessController.doPrivileged()and there's a good little tutorial on it at the Java Ranch FAQ.我有一个类似的问题，花了很长时间才解决。 事实证明，从 JavaScript 调用的小程序方法没有权限，即使您在策略文件中明确授予它们也是如此。
此解决方法对我有用（将命令添加到小程序循环通过的队列）：
http://blog.carrythezero.com/?p=5
确保您了解其中的危险此处：任何人都可以修改页面上的 JavaScript 并更改输入到小程序中的内容。 就我而言，我知道代码永远不会在网络服务器上运行，并且该类未签名，因此除非位于我的策略文件授予的特定位置，否则它将失败。
I had a similar problem which took forever to solve. It turns out applet methods called from JavaScript have no permissions, even if you explicitly grant them in a policy file.
This workaround worked for me (adding commands to a queue which the applet loops through):
http://blog.carrythezero.com/?p=5
Make sure you understand the dangers here: Anyone can modify JavaScript on a page and change what's getting fed into the applet. In my case I know the code is never going on a webserver, and the class is unsigned so it will fail unless in the specific location granted by my policy file.
这可能是因为 JavaScript 未签名。 我强烈建议不要签署代码，特别是当您不知道自己在做什么时。 从 6u10（尚未在 Mac 上）开始，小程序可以使用 JNLP，包括 FileOpenService，因此您无需签名。
It's probably because the JavaScript is unsigned. I strongly suggest not signing code, particularly if you don't know what you are doing. From 6u10 (not on Mac yet) applets can use JNLP including the FileOpenService, so you don't have to sign.