Копирование/вставка не работает в подписанном апплете

У меня есть подписанный апплет (который правильно проверяется с помощью jarsigner), который по какой-то причине не позволяет копировать и вставлять из системного буфера обмена в JTextField, несмотря на то, что в документации говорится, что он должен работать для подписанных апплеты.

Кроме того, у меня есть другие апплеты, подписанные тем же ключевым файлом, которые позволяют копировать и вставлять текст. Я искал в Интернете повсюду и не мог найти никаких подсказок. Что заставляет меня рвать на себе волосы, так это то, что, похоже, нет способа отладить это (нет вывода в консоль - нет выброшенных исключений).

Есть ли у кого-нибудь идеи о том, как я могу отладить это, чтобы выяснить, почему Java не нравится этот конкретный апплет?

Большое спасибо за любые предложения!


person user1098932    schedule 15.12.2011    source источник


Ответы (4)


Что ж, оказывается, с выпуском плагина Java 1.6.0_24 в феврале 2011 года копирование и вставка из системного буфера обмена было признано дырой в безопасности и отключено. Вы можете копировать и вставлять МЕЖДУ апплетами. Но если вы попытаетесь использовать что-то из основного буфера обмена, это нельзя будет скопировать.

Итак, есть несколько вариантов обходного пути. Вы можете вернуться к более ранней версии плагина. Это сработает, но есть вероятность, что все будущие выпуски по-прежнему будут отключать копирование и вставку, поэтому вы никогда не сможете обновиться.

Другой альтернативой является предоставление пользовательского файла политики безопасности Java, который снова разрешает доступ к системному буферу обмена.

Сначала найдите локальный файл политики безопасности Java. Файл называется java.policy и должен находиться в папке lib\security вашей установки Java. В Windows 7 его можно найти в папке C:\Program Files (x86)\Java\jre6\lib\security. Скопируйте этот файл в свою домашнюю папку (например, C:\Users\Kyle). Переименуйте файл в .java.policy (обратите внимание на точку в начале). Отредактируйте файл в текстовом редакторе. Найдите эту строку текста:

// "standard" properies that can be read by anyone

Добавьте следующую строку чуть ниже:

// "standard" properies that can be read by anyone
permission java.awt.AWTPermission "accessClipboard";

Сохраните файл. Перед тестированием закройте все открытые браузеры и убедитесь, что Java не запущена.

источник: http://blogs.oracle.com/kyle/entry/copy_and_paste_in_java

person Dennis    schedule 15.12.2011
comment
Спасибо - я видел это, но у меня сложилось впечатление, что это было отключено только для НЕПОДПИСАННЫХ апплетов (согласно моим исследованиям). Подписанные апплеты должны по-прежнему работать, а другой подписанный апплет в настоящее время позволяет копировать и вставлять. Есть еще идеи? - person user1098932; 15.12.2011
comment
Какую версию java-плагина вы используете? В каком браузере вы это тестируете? Вы получаете приглашение разрешить/запретить службу копирования/вставки? Вы проверили демонстрацию clipService? pscode.org/jws/api.html#cbs - person Dennis; 15.12.2011
comment
Это апплет, развернутый на многих JVM в нескольких корпорациях. В настоящее время я запускаю 1.6.0_26, и мне не предлагается разрешить/запретить службу копирования/вставки. Если я добавлю код для обработки доступа к системному буферу обмена, это позволит мне, и я смогу вставить его в поле. - person user1098932; 16.12.2011
comment
@ user1098932: У меня такая же проблема. Я добавил accessClipboard в свою политику. Я тоже подписал свой апплет (но он самоподписанный, а не доверенный). Я думаю, что он будет работать нормально, но ошибка отказа в доступе все еще возникает. Некоторые блоги сообщили мне, что апплет самоподписания может работать в боковой песочнице в среде разработки (в этом случае это мой компьютер). Можете ли вы сказать мне, что это правда? - person Ken Block; 23.06.2014
comment
Почему в файле java.policy написано properies, а не properties, а properies - person Morteza Tourani; 21.11.2017

Помимо обзора Денниса, см. раздел Копировать в изолированном приложении. в версии 1.6.0_24+ в OTN.

Хотя копирование Ctrl-c больше не работает по умолчанию, можно снова добавить функциональность для любого апплета, запускаемого в подключаемом модуле Java «следующего поколения». Поскольку Java Web Start существовал, JWS предоставлял изолированную копию через. API JNLP javax.jnlp.ClipboardService, начиная с Sun 1.6.0_10 и следующего поколения. плагин, встроенные апплеты могут быть развернуты с помощью JWS и могут получить доступ к API JNLP.

Смотрите также

person Andrew Thompson    schedule 15.12.2011
comment
интересно (а также @user1098932) - почему исправление безопасности влияет на подписанные апплеты/вебстартабли? Может быть, я упускаю суть - что, по моему мнению, заключается в том, чтобы разрешить вещи, которые отключены в изолированных контекстах? - person kleopatra; 15.12.2011
comment
@kleopatra Проблема сложная и тонкая, и я не претендую на полное понимание. Лучше всего это было объяснено в записи блога Сами Койву на Multiple Java Уязвимости буфера обмена для апплетов (ссылка из ветки OTN). К сожалению, запись в блоге Кайла, а также ответ Денниса (как и большинство людей, читающих эту ветку, по-видимому), упущены, так это то, что это можно исправить с помощью ClipboardService. :( - person Andrew Thompson; 15.12.2011
comment
да, в курсе о блоге Сами и ClipboardService, но он говорит о том, что потенциально опасный код Java из ненадежного источника получает доступ для чтения/записи к системному буферу обмена (уязвимости 1 и 2) и полное повышение привилегий для выполнения что-либо с привилегиями пользователя .. и его комментарий к требованию для c&p соответствует моим ожиданиям Я полагаю, что если вы сможете подписать свой апплет, это решит проблему Мой потенциально наивный: - ) дело в том, что если я прохожу через все трудности с подписанием, мне вообще не нужно беспокоиться об ограничениях безопасности - person kleopatra; 15.12.2011
comment
Даже доверенный апплет (обычно) имеет песочницу. Такие вещи, как System.exit(n), никогда не должны вызываться в апплете. Что касается проблем, которые это может вызвать из-за того, что доверенный апплет точно использует буфер обмена, я должен признать, что не знаю. Лучшее объяснение, которое я могу предложить, заключается в том, что, возможно, они придерживаются позиции Лучше перестраховаться, чем потом сожалеть. - person Andrew Thompson; 15.12.2011

Я не уверен, почему, но объект JTextField, который я использую, не кажется должным образом связанным с ключевыми событиями (может быть, потому, что я добавил FocusListener?), но добавив следующий код:

    searchTextField.addKeyListener(new java.awt.event.KeyListener() {
        public void keyPressed(KeyEvent e) {
            //System.out.println("KEY:"+e);
            if (e.getKeyCode() == 86 && ((e.getModifiers() & KeyEvent.CTRL_MASK) != 0)) {
                java.awt.datatransfer.Clipboard clipboard = java.awt.Toolkit.getDefaultToolkit().getSystemClipboard();
                java.awt.datatransfer.Transferable clipData = clipboard.getContents(clipboard);
                String s;
                try {
                    s = (String)(clipData.getTransferData(java.awt.datatransfer.DataFlavor.stringFlavor));
                } catch (Exception ex) {
                    s = ex.toString();
                }
                searchTextField.setText(s);
            }
        }
        public void keyReleased(KeyEvent e) {
        }
        public void keyTyped(KeyEvent e) {
        }
    });

...позволяет вставить в поле.

person user1098932    schedule 15.12.2011

  1. Сделайте резервную копию java.policy, которая находится по адресу (пример: C:\Program Files (x86)\Java\jre7\lib\security)

  2. Найдите строку в java.policy файле // "standard" properies that can be read by anyone

  3. Затем измените java.policy и добавьте, как показано ниже.

// "standard" properies that can be read by anyone permission java.security.AllPermission;

person Aravind    schedule 19.04.2019