Как симулировать модальный диалог из апплета? - PullRequest
Новая
       21

Как симулировать модальный диалог из апплета?

4 голосов
/ 30 апреля 2009

В 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) { }
}

Это прекрасно работает в большинстве браузеров. Однако в Opera и Safari для 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)

Есть ли обходной путь для создания поддельных модальных диалогов в этих браузерах?

Ответы [ 4 ]

1 голос
/ 12 мая 2009

Вам не нужно подписывать апплет, чтобы это работало?

Подписание апплета

Способ разрешить апплету делать все эти вещи - это подписать его цифровой подписью. По сути, подписывающее лицо говорит: «Этот апплет безопасен в использовании, и если вы доверяете мне, вы можете доверять этому апплету, потому что благодаря моей подписи вы можете быть уверены, что он не был подделан с тех пор, как я подписал его». Затем пользователю будет задан вопрос, хочет ли он доверять подписывающему лицу (обычно в небольшом диалоговом окне), и если он это делает, апплет может продолжить работу с полными привилегиями. Если доверие отказано, апплет продолжает работать в песочнице с ограниченными привилегиями.

Решение о том, следует ли доверять апплету, должно приниматься очень разумно, поскольку доверенный апплет имеет те же привилегии, что и приложение, запускаемое локально: оно может читать и удалять файлы, а также передавать данные по сети.

Более подробное объяснение модели безопасности апплета можно найти здесь. Это включает полный список ограничений апплета.

Для ознакомления с подписью апплета и ссылками на дополнительную информацию прочитайте это и особенно это. Internet Explorer (и MS JVM) немного нестандартны; Прочитайте это для обзора того, что делать.

Если даже после подписания апплета вы по-прежнему получаете исключение SecurityException, попробуйте запустить код как привилегированный код:

AccessController.doPrivileged (новая привилегированная операция () { public Object run () { // выполняем чувствительную к безопасности операцию здесь вернуть ноль; } });

JavaDoc: java.security.AccessController

Файлы политики

Альтернативным способом предоставления апплету дополнительных возможностей является использование файлов политик, о которых у Sun есть вводная статья, а еще одна - специально для апплетов. Используя политики, можно более детально контролировать, какие привилегии предоставлять апплету. Например, становится возможным предоставить апплетам доступ к локальной файловой системе, но не к каким-либо другим возможностям, в которых им отказано. Вот пример этого.

Недостатком использования файлов политики является то, что они находятся в локальной файловой системе, поэтому пользователи должны вносить изменения в файл, который обычно не виден им, и содержимое которого нетривиально для понимания.

В следующем примере показано, как отменить большинство ограничений апплета. Любое из разрешений может быть сделано более конкретным, например, FilePermission может быть предоставлено только для выбранных файлов и с доступом только для чтения. Javadocs для каждого класса Разрешения подробно объясняют, что возможно. Рекомендуется использовать максимально ограниченную настройку. В частности, RuntimePermission можно использовать для создания ClassLoaders и SecurityManager, которые могут обойти даже больше ограничений апплета. 

 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

1 голос
/ 07 мая 2009

Если бы я мог предложить другой подход, который мог бы работать, вместо перехвата событий в потоке событий, вы могли бы использовать стеклянную панель, чтобы заблокировать все входные запросы .

1 голос
/ 07 мая 2009

Причиной возникновения проблемы с Opera может быть то, что Opera имеет свой собственный файл java.policy, называемый opera.policy (в папке Opera_installation_directory \ classes). Хотя в моей установке Opera я не мог видеть никаких разрешений, которые не предоставлены в Opera, но предоставлены в файле java.policy по умолчанию.

1 голос
/ 30 апреля 2009

Это разрешение должно быть предоставлено, если у вас нет странной реализации (Sun PlugIn предоставляет его с 1.2.2, IIRC). О каких версиях мы говорим?

Вероятно, это не лучший цикл отправки.

Вы, вероятно, должны позвонить isVisible с EDT.

Модальные интерфейсы, как правило, противны.

Что не так с модальным диалогом?

...