Привет, любимый читатель.
Сегодня ты узнаешь как подписать JAVA апплет. Для начала скажу, что JAVA апплеты имеют ограниченную функциональность, пока они не подписаны. Например, неподписанные апплеты не могут:
Вариантов решения проблемы несколько:
1. Разрешить выполнение на каждой локальной машине клиентов. Для этого можно отредактировать файл java.policy, который находится в папке с установленным JRE (по умолчанию в C:\Program Files\Java\jre6\lib\security). И добавить необходимые разрешения. Например, чтобы разрешить все, что можно, нужно вставить строчку:
А если нужно разрешить только работу с буфером обмена для сайта hackmeplease.com:
Этот способ будет удобен только в том случае, если кол-во конечных пользователей твоего сайта ограничено и тебе не в лом на каждом компьютере править этот файл. Кроме того безопасность этого решения не очень высока.
2. Подписать свой Java-апплет. Итак, что имеем на входе:
— установленные JDK и JRE;
— jar-файл своего апплета (есть некоторые особенности написания исходного кода, см. ниже);
— желание работать с буфером обмена. Для этого нужно, чтобы корректно работала строчка:
Toolkit toolkit = Toolkit.getDefaultToolkit();
Clipboard clipboard = toolkit.getSystemClipboard();
В случае вызова этих строчек, из неподписанного апплета получим следующее исключение:
java.security.AccessControlException: access denied (java.awt.AWTPermission accessClipboard)
Итак, приступим:
0. Переходим в папку BIN нашего JDK (например, C:\Program Files\Java\jdk1.6.0_23\bin).
I. Создаем локальное хранилище нашего сертификата (keystore):
keytool -genkey -keystore .keystore -alias «Terrasoft» -validity 99999
где Terrasoft — название alias нашего сертификата;
99999 — срок в месяцах валидности сертификата;
.keystore — имя файла создаваемого хранилища.
В случае успешного запуска команды, система спросит нас пароль нашего хранилища, а также некоторую информацию о сертификате (твои ФИО, название компании, город, страну и группу крови)
В результате будем иметь файл .keystore. Это и есть наше хранилище, которым мы будем подписывать разные апплеты.
II. Копируем в папку BIN нашего JDK наш JAR-файл. Подписываем его с помощью следующей команды:
jarsigner.exe -keystore .keystore ClipboardLibrary.jar «Terrasoft»
где Terrasoft — название alias нашего сертификата;
.keystore — имя файла хранилища;
ClipboardLibrary.jar — название JAR-файла.
Система спросит нас пароль — вводим тот, что ввели в п. I.
Вроде как готово… Да щас, наивный…
Итак, при запуске страницы с нашим апплетом на борту пользователь получит дружественное сообщения вида:
Что означает, «Пользователь, нажми Да и попрощайся со своей системой, ибо мы сможем с ней делать, что захотим».
Кстати, обратите внимание на NOT VERIFIED. Означает, что у нас не доверительный сертификат. Чтобы получить доверительный, нужно обращаться в специальные службы в инете и даже платить деньгу.
Но вернемся к нашим баранам. При обращении к буферу обмена мы снова получим исключение вида:
java.security.AccessControlException: access denied (java.awt.AWTPermission accessClipboard)
Очень жаль. Ну что же, не получилось сейчас — получится в другой раз. До свидания.
Шучу. На самом деле на этом моменте останавливаются все руководства по подписыванию апплетов, которые я встречал. Мол, подписанному апплету ничего не страшно. Пусть им всем будет стыдно.
Короче, следующий финт для того, чтобы наше обращение к буферу обмена заработало:
III. Изменить исходный код.
Вместо вызова вида:
нужно написать вызов вида:
После этого нужно перекомпилировать свой JAR и повторить шаг II (тем, кто читал с конца мое сообщение — респект).
Вот в общем-то и все. Должно работать. Надеюсь, что кому-то это пригодится, и он не будет столько своей жизни тратить на эту ерунду, сколько потратил я. Нехай проблеми i негоди не роблять вам в життi погоди (С). До новых встреч в эфире.
Сегодня ты узнаешь как подписать JAVA апплет. Для начала скажу, что JAVA апплеты имеют ограниченную функциональность, пока они не подписаны. Например, неподписанные апплеты не могут:
- взаимодействовать с локальной файловой системой клиента;
- устанавливать сетевые соединения с другими серверами;
- взаимодействовать с буфером обмена клиента;
- некоторые другие.
Вариантов решения проблемы несколько:
1. Разрешить выполнение на каждой локальной машине клиентов. Для этого можно отредактировать файл java.policy, который находится в папке с установленным JRE (по умолчанию в C:\Program Files\Java\jre6\lib\security). И добавить необходимые разрешения. Например, чтобы разрешить все, что можно, нужно вставить строчку:
grant {
...
permission java.security.AllPermission;
}
А если нужно разрешить только работу с буфером обмена для сайта hackmeplease.com:
grant codeBase "http://hackmeplease.com/*" {
permission java.awt.AWTPermission "accessClipboard";
};
Этот способ будет удобен только в том случае, если кол-во конечных пользователей твоего сайта ограничено и тебе не в лом на каждом компьютере править этот файл. Кроме того безопасность этого решения не очень высока.
2. Подписать свой Java-апплет. Итак, что имеем на входе:
— установленные JDK и JRE;
— jar-файл своего апплета (есть некоторые особенности написания исходного кода, см. ниже);
— желание работать с буфером обмена. Для этого нужно, чтобы корректно работала строчка:
Toolkit toolkit = Toolkit.getDefaultToolkit();
Clipboard clipboard = toolkit.getSystemClipboard();
В случае вызова этих строчек, из неподписанного апплета получим следующее исключение:
java.security.AccessControlException: access denied (java.awt.AWTPermission accessClipboard)
Итак, приступим:
0. Переходим в папку BIN нашего JDK (например, C:\Program Files\Java\jdk1.6.0_23\bin).
I. Создаем локальное хранилище нашего сертификата (keystore):
keytool -genkey -keystore .keystore -alias «Terrasoft» -validity 99999
где Terrasoft — название alias нашего сертификата;
99999 — срок в месяцах валидности сертификата;
.keystore — имя файла создаваемого хранилища.
В случае успешного запуска команды, система спросит нас пароль нашего хранилища, а также некоторую информацию о сертификате (твои ФИО, название компании, город, страну и группу крови)
В результате будем иметь файл .keystore. Это и есть наше хранилище, которым мы будем подписывать разные апплеты.
II. Копируем в папку BIN нашего JDK наш JAR-файл. Подписываем его с помощью следующей команды:
jarsigner.exe -keystore .keystore ClipboardLibrary.jar «Terrasoft»
где Terrasoft — название alias нашего сертификата;
.keystore — имя файла хранилища;
ClipboardLibrary.jar — название JAR-файла.
Система спросит нас пароль — вводим тот, что ввели в п. I.
Вроде как готово… Да щас, наивный…
Итак, при запуске страницы с нашим апплетом на борту пользователь получит дружественное сообщения вида:
Что означает, «Пользователь, нажми Да и попрощайся со своей системой, ибо мы сможем с ней делать, что захотим».
Кстати, обратите внимание на NOT VERIFIED. Означает, что у нас не доверительный сертификат. Чтобы получить доверительный, нужно обращаться в специальные службы в инете и даже платить деньгу.
Но вернемся к нашим баранам. При обращении к буферу обмена мы снова получим исключение вида:
java.security.AccessControlException: access denied (java.awt.AWTPermission accessClipboard)
Очень жаль. Ну что же, не получилось сейчас — получится в другой раз. До свидания.
Шучу. На самом деле на этом моменте останавливаются все руководства по подписыванию апплетов, которые я встречал. Мол, подписанному апплету ничего не страшно. Пусть им всем будет стыдно.
Короче, следующий финт для того, чтобы наше обращение к буферу обмена заработало:
III. Изменить исходный код.
Вместо вызова вида:
clipboard = toolkit.getSystemClipboard()
нужно написать вызов вида:
clipboard = (Clipboard) AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
return toolkit.getSystemClipboard();
}
});
После этого нужно перекомпилировать свой JAR и повторить шаг II (тем, кто читал с конца мое сообщение — респект).
Вот в общем-то и все. Должно работать. Надеюсь, что кому-то это пригодится, и он не будет столько своей жизни тратить на эту ерунду, сколько потратил я. Нехай проблеми i негоди не роблять вам в життi погоди (С). До новых встреч в эфире.
