Подписи в аплетах — как это делается ?

 

Решил подготовить небольшую статью о том, как создаются подписи для аплетов и как это все работает.

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

В этом случае я жду Ваших пожеланий и комментариев. Текст программы я сочинил не сам — подсмотрел. Но все остальное проверил и протестировал. Так что пользуйтесь 🙂

Итак, начнем с самого начала и напишем небольшой аплет, который умеет читать файл с диска.

Вот сам код аплета

А вот и примерчик HTML (ReadFileApplet.htm), который запустит ваш код.

 

После того, как вы скопировали эти примеры :), давайте их соберем в JAR-архив. Первым делом запустим компилятор JAVA,

а второй командой соберем получившиеся class-файлы в JAR-архив

 

Ключ c говорит о том, что надо создать архив. Ключ f говорит что надо отправить результат в файл rfa.jar. Последним идет список фалов. Теперь у нас есть JAR-файл и вы можете (это лучше сделать сейчас) удалить файлы *.class.

Итак, мы подготовили обычный аплет. Давайте проверим его работоспособность. Запускаем:

 

Аплет по идее должен загрузиться и мы теперь нажимаем кнопку «Read Local File». И получаем само собой предупреждение, что мы этого не можем делать

java.security.AccessControlException: access denied (java.io.FilePermission C:\AUTOEXEC.BAT read)

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

Теперь приступим к подписанию нашего аплета. Первое, что мы должны сделать, это сгенерировать пару ключей закрытый/открытый и поместить эту пару в некое хранилище. Для серьезных приложений такие хранилища в Интеренете содержат специальные уполномоченные фирмы.

Нам это в данный момент недоступно и мы создадим свое локальное хранилище. Итак, запускаем следующую команду

 

Утилита keytool предназначена для многих целей, но мы ее используем для генерации ключа. Что указывает ключ -genkey. Пара ключей помещается в файл-хранилище .keystore (это говорит опция -keystore) и этой паре присваивается алиас «Vingrad» (ключ -alias)

Сначала утилита спросит пароль для хранилища. Можно ввести что-то запоминающееся — например, 123456.

Запомните этот пароль — он нам еще пригодится.

После этого будут заданы вопросы, на которые можно просто нажимать <ENTER>. Только подтверждение должно содержать yes

Теперь по идее в нашем каталоге появился файл .keystore. И теперь мы можем подписать наш JAR-архив. Для подписи арзива используем утилитуjarsigner.

ОБЯЗАТЕЛЬНО: Не забудьте выйти из appletviewer, т.к. в противном случае JAR-файл невозможно будет изменить

 

Ключ -keystore (как Вы наверняка догадались) используется для указания, из какого хранилища брать ключи подписи. Далее следует имя JAR-архива и потом алиас — кто подписывает данный JAR.

У вас будет запрошен пароль (Вы его должны были запомнить) после чего утилита обработает Ваш архив. Если никаких сообщений об ошибках не было Вы может посмотреть содержимое JAr-файла и обнаружить, что в директории META-INF находится файл vingrad.sf. Это как раз подпись.

И теперь мы можем еще раз запустить наш аплет. Как и в прошлый раз

 

Нажимаем и … опять ничего не работает. Все верно. мы должны также указать в политике безопасности, что мы можем доверять аплетам, которые подписал «Vingrad».

Для этого надо сделать две вещи:

1. Указать JAVA_HOME. Указать его лучше всего на каталог с SDK

2. И в файл $JAVA_HOME\jre\lib\security\java.policy добавить следующие строки:

И вот теперь мы можем попробовать еще раз

 

На этот раз должно все сработать (если Вы ничего не перепутали)

 

А теперь давайте запустим наш аплет в настоящем броузер. Я использовал IE 6 с установленной JAVA-машиной от Sun. В этом случае при загрузке апплета броузер задаст Вам вопрос — доверяете ли вы данной подписи.

У Вас есть выбор — Yes, No, Always (Да, Нет, Всегда).

Если Вы ответите «ДА», то аплет сможет прочитать файл. Но если Вы захотите повторно загрузить этот

аплет, Вас опять спросят о доверии. Если «НЕТ — то аплет не сможет прочитать файл. Если же Вы ответите «ВСЕГДА», то после этого сколько бы Вы не загружали страничку, ничего Вас спрашивать не будут. Сделайте так. Убедились ?

 

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

 

Запустите «Панель управления» и там Вы увидите пункт «Java Plug-In». Давайте запустим. Вы увидите несколько закладок. Из них нас интересует одна — «Sertificates». И там, о чудо, там то, что нам надо — там появился наш сертификат, который говорит о том, что доверять можно. Если Вы удалите его, то следующая загрузка странички породит опять вопрос о доверии.

 

Небольшое дополнение насчет файла java.policy. Этот файл нужен, чтобы пользователю не выводилось предупреждений.

Т.е. если он есть, и в нем прописан данный производитель ПО, то пользователю не будет выдаваться запросов и предупреждений, апплет сразу получит права прописанные в policy файле.

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

 

В общем-то и все. Все Ваши комментарии и замечания будут приняты с благодарностью.

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.