如何在Applet中模擬模式對話框?

[英]How do I simulate a modal dialog from within an Applet?


On setVisible(true), I call the following code to start a modal dialog:

在setVisible(true)上,我調用以下代碼來啟動模式對話框:

private synchronized void startModal () {
  try {
    if (SwingUtilities.isEventDispatchThread()) {
      EventQueue theQueue = getToolkit().getSystemEventQueue();
      while (isVisible()) {
        AWTEvent event = theQueue.getNextEvent();
        Object source = event.getSource();
        if (event instanceof ActiveEvent) {
          ((ActiveEvent) event).dispatch();
        } else if (source instanceof Component) {
          ((Component) source).dispatchEvent(event);
        } else if (source instanceof MenuComponent) {
          ((MenuComponent) source).dispatchEvent(event);
        } else {
          System.err.println("Unable to dispatch: " + event);
        }
      }
    } else {
      while (isVisible()) {
        wait();
      }
    }
  } catch (InterruptedException ignored) { }
}

This works just great in most browsers. However, in Opera and Safari for Windows, I am confronted with the following big-nasty-exception:

這在大多數瀏覽器中都很有效。但是,在Opera和Safari for Windows中,我遇到了以下令人討厭的異常:

java.security.AccessControlException: access denied (java.awt.AWTPermission accessEventQueue)
    at java.security.AccessControlContext.checkPermission(Unknown Source)
    at java.security.AccessController.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkAwtEventQueueAccess(Unknown Source)
    at java.awt.Toolkit.getSystemEventQueue(Unknown Source)

Is there a workaround for generating fake-modal dialogs in these browsers?

是否有在這些瀏覽器中生成假模態對話框的解決方法?

4 个解决方案

#1


That permission should be granted unless you have a strange implementation (Sun PlugIn has been granting it since 1.2.2, IIRC). Which versions are we talking about?

除非你有一個奇怪的實現(Sun PlugIn自1.2.2,IIRC以來一直授予它),否則應該授予該權限。我們在談論哪些版本?

That probably isn't the best dispatch loop.

這可能不是最佳的調度循環。

You probably should call isVisible off the EDT.

你可能應該在EDT上打電話給isVisible。

Modal interfaces are generally nasty.

模態界面通常很討厭。

What's wrong with a modal dialog?

模態對話框出了什么問題?

#2


If I might offer a different approach that could work, instead of intercepting the events in the event thread, you could use the glass pane to block all input requests.

如果我可以提供一種可行的不同方法,而不是攔截事件線程中的事件,則可以使用玻璃窗格來阻止所有輸入請求。

#3


Don't you need to sign your applet in order this to work?

您是否需要簽署您的小程序才能使用?

Signing an applet

簽署applet

The way to allow an applet to do all those things is to digitally sign it. In effect the signer says "This applet is safe to use, and if you trust me, you can trust this applet, because through my signature you can be assured that it has not been tampered with since I signed it." The user will then be asked if she wants to trust the signer (usually in a little dialog box), and if she does, the applet can proceed with full privileges. If the trust is denied, the applet continues to run inside the sandbox with limited privileges.

允許applet完成所有這些操作的方法是對其進行數字簽名。實際上,簽名者說“這個applet可以安全使用,如果你相信我,你可以信任這個applet,因為通過我的簽名,你可以放心,自從我簽名以來它沒有被篡改過。”然后將詢問用戶是否想要信任簽名者(通常在一個小對話框中),如果她這樣做,則applet可以繼續使用完全權限。如果信任被拒絕,則applet將繼續在具有有限權限的沙箱內運行。

The decision of whether to trust an applet should be made very judiciously, because a trusted applet has the same privileges a locally started application would have: It can read and delete files, and transmit data over the network.

是否應該非常謹慎地決定是否信任applet,因為受信任的applet具有本地啟動的應用程序所具有的相同權限:它可以讀取和刪除文件,並通過網絡傳輸數據。

A more thorough explanation of the applet security model can be found here. That includes a full list of the applet restrictions.

可以在此處找到有關applet安全模型的更全面的解釋。這包括applet限制的完整列表。

For an introduction to applet signing and links to more information read this and especially this. Internet Explorer (and the MS JVM) are a bit non-standard; read this for an overview of what to do.

有關applet簽名的介紹和更多信息的鏈接,請閱讀此內容,尤其是此內容。 Internet Explorer(和MS JVM)有點不標准;閱讀本文,了解如何做的概述。

If, even after signing the applet, you still get a SecurityException, try running the code as privileged code:

如果,即使在簽署applet之后,仍然會收到SecurityException,請嘗試將代碼作為特權代碼運行:

AccessController.doPrivileged(new PrivilegedAction() { public Object run() { // perform the security-sensitive operation here return null; } });

AccessController.doPrivileged(new PrivilegedAction(){public Object run(){//執行安全敏感操作,返回null;}});

JavaDoc:java.security.AccessController

Policy files

An alternative way to grant an applet additional capabilities is the use of Policy files, about which Sun has an introductory article, and another one here specifically for applets. Using policies it is possible to control in a more fine-grained way which privileges to grant an applet. E.g., it becomes possible to grant applets access to the local file system, but not any of the other capabilities they are denied. Here is an example of that.

授予applet附加功能的另一種方法是使用策略文件,Sun有一篇介紹性文章,另一篇專門針對applet。使用策略可以以更細粒度的方式控制授予applet的權限。例如,可以授予applet訪問本地文件系統的權限,但不允許其被拒絕的任何其他功能。這是一個例子。

The drawback to using policy files is that they reside on the local file system, so users must make changes to a file that is normally out of their sight, and the contents of which are not trivial to understand.

使用策略文件的缺點是它們駐留在本地文件系統上,因此用戶必須對通常不在其視線范圍內的文件進行更改,並且其內容並非易於理解。

The following example shows how to revoke most of an applets restrictions. Any of the permissions can be made more specific, e.g. FilePermission can be given for only selected files, and with read-only access. The javadocs for each Permission class explain in detail what's possible. It is good practice to use the most restricted setting possible. RuntimePermission in particular can be used to create ClassLoaders and SecurityManagers, which can circumvent even more applet restrictions.

以下示例顯示如何撤消大多數applet限制。可以使任何權限更具體,例如FilePermission只能用於選定的文件,並具有只讀訪問權限。每個Permission類的javadoc詳細解釋了什么是可能的。優良作法是盡可能使用最受限制的設置。特別是RuntimePermission可用於創建ClassLoaders和SecurityManagers,它可以規避更多的applet限制。

 grant codeBase "http://geosim.cs.vt.edu/geosim/-" {
   permission java.io.FilePermission "<<ALL FILES>>", "read, write, execute, delete";
   permission java.net.SocketPermission "*", "accept, connect, listen, resolve";
   permission java.util.PropertyPermission "*", "read, write";
   permission java.lang.RuntimePermission "*";
   permission java.awt.AWTPermission "showWindowWithoutWarningBanner";
 };

Javadocs

JavaDoc:java.awt.AWTPermission JavaDoc:java.io.FilePermission JavaDoc:java.lang.RuntimePermission JavaDoc:java.net.SocketPermission JavaDoc:java.util.PropertyPermission

JavaDoc:java.awt.AWTPermission JavaDoc:java.io.FilePermission JavaDoc:java.lang.RuntimePermission JavaDoc:java.net.SocketPermission JavaDoc:java.util.PropertyPermission

#4


The reason of having a problem with Opera might be that Opera has its own java.policy file named as opera.policy (under Opera_installation_directory\classes folder). Though, in my Opera installation, I couldn't see any permission that is not granted in Opera but granted in the default java.policy file.

出現Opera問題的原因可能是Opera有自己的java.policy文件,名為opera.policy(在Opera_installation_directory \ classes文件夾下)。雖然,在我的Opera安裝中,我看不到任何未在Opera中授予但在默認java.policy文件中授予的權限。


注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:https://www.itdaan.com/blog/2009/04/29/721129c027d570dd3a136fb58cd737a4.html



 
粤ICP备14056181号  © 2014-2021 ITdaan.com