Для установки и последующей настройки КриптоПро системы «Банк-клиент Онлайн» вам потребуется скачать java апплет для «ВТБ 24». Скачать можно бесплатно на страничке http://www.java.com/ru/ . Этот компонент понадобиться, если вы будите использовать в своей работе такие браузеры, как Mozilla Firefox, Opera, Internet Explorer. Но это не единственные браузеры, которые поддерживает данная система.
Установка java апплет проходит в два этапа:
Если java стоит на вашем персональном компьютере, первый этап следует пропустить. Кстати, ПК не попросит вас установить данный компонент. Установка проходит в пять шагов:
Настройка осуществляется через «Пуск» в «Панеле управления». Затем откройте контрольную панель. Вам останется только произвести отключение протоколов: TLS 1.1 и TLS 1.2. Сделать это просто: снимите с них галочки напротив. Аналогичным образом отключаем «Use SSL 2.0 compatible ClientHello format». Все готово.
Много-много лет назад, работая админом на одном из градообразующих предприятий российской глубинки, мне пришлось впервые столкнуться с понятием «электронно-цифровая подпись» (далее ЭЦП).
В головах руководства, на тот момент, укоренилась мысль, что ЭЦП - это обычная подпись, отсканированная и добавляемая на все документы, которые должны быть «подписаны».
Давайте разбёрмся, что же такое ЭЦП и как она работает.
Для работы с ЭЦП нам, прежде всего, необходим цифровой сертификат и закрытый ключ.
Сначала, нам необходимо установить ЭЦП под документом.
Установка ЭЦП происходит в два шага:
1. Берём документ, который мы хотим подписать и вычисляем хэш от этого документа. (Упрощённо, хэш - это односторонняя математическая функция преобразования документа произвольной длинны, в документ фиксированной длинны).
2. Затем, этот полученный хэш шифруем нашим закрытым ключом. 
Теперь документ, с прикреплённой к нему ЭЦП и нашим сертификатом, отправляем получателям.
Получив подписанный документ, нам необходимо проверить подпись - действительна она или нет.
Проверка ЭЦП происходит несколько сложнее:
1. Берём документ, подпись под которым необходимо проверить, вычисляем хэш от этого документа.
2. Берём цифровой сертификат пользователя, который подписал документ и прикреплённую к документу ЭЦП (которая является зашифрованым на закрытом ключе подписсанда хэшом оригинального документа) и расшифровываем с помощью открытого ключа.
Таким образом, у нас есть два хэша - тот, который мы вычислили сами и тот, который мы получили вместе с документом и расшифровали открытым ключом подписанта.
3. Теперь сравниываем эти хэши. Если хэши совпадают, значит подпись действительна, если хэши различаются, значит подпись неделйствительна.
В заключении определим, что нам даёт использование цифровой подписи:
1. Неизменяемость в процессе передачи или хранения - если документ был изменён, то хэш, который мы вычислим, и который был прикрёплён к документу, буду разные, следовательно, подпись будет неделйстительная, из чего можно сделать вывод, что документ был изменён;
2.
Для того, чтобы было невозможно подделать ЭЦП, закрытый ключ должен быть в единственном экземпляре и доступ к нему должен быть только у владельца. Это можно реализовать используя смарт-карты, но это уже совсем другая история.
Проблема в следующем.
На странице размещен некоторый апплет, а также интерфейс для управления им, написанный на HTML + JavaScript. Требуется определить из JavaScript, что апплет загружен и готов к работе. Решение должно быть ПРЕДЕЛЬНО надежным - кросс-броузерным, нормально реагирующим на медленный Internet и т.п.
Комментирую. Пока апплет не загрузился, обращения из JavaScript к его public-методам и/или полям чреваты появлением весьма некрасивого сообщения примерно такого содержания: "Данный метод отсутствует". А апплет порой загружается намного дольше, чем сама страница. Более того, некоторые вещи иногда имеет смысл сделать автоматически (из JavaScript), как только апплет загрузится - скажем, подать ему некоторую команду.
Здесь проблема не столько в том, что нет способа проверить, что апплет уже загрузился, сколько в изобилии таких способов. Например: onload у апплета, onload у страницы, обращение к методу или полю апплета, "активное" информирование страницы о загруженности апплета специальным Java-кодом изнутри самого апплета, и т.д. А уверенности, что эти способы будут работать:
на всех мыслимых броузерах,
при всех настройках Security в броузерах,
в сочетании со всеми мыслимыми платформами,
со всеми JRE,
у меня нет. И получить такую уверенность почти нереально: слишком много комбинаций.
Хуже того, здесь, кажется, очень легко "перемудрить". Например, я вчера долго "боролся" с ошибкой - на чужом компьютере (XP+ MSIE +Java2) JavaScript ошибочно полагал, что апплет не загружен, хотя у меня на компьютере все было в порядке. Подозреваю, дело в том, что я тогда использовал для проверки доступности обращение к некой public-переменной апплета (не методу!). Все броузеры на моем компьютере (тоже XP) при обращении к такой переменной недозагруженного апплета возвращают null, а как только апплет загрузится - возвращают ее значение. (В отличие от этого, обращение к методу недозагруженного апплета выдает ошибку.) Боюсь, что на чужом компьютере броузер отказался считывать public-переменную. Доступ к переменным - вообще неочевидная вещь, работающая по-разному из-под разных броузеров и JRE. Надежен только вызов методов, но - лишь когда апплет загружен.
Пока что я написал следующую пару функций:
Function showMyErrorMessage(msg,url,line) { if (window.errorMessage != null) alert(window.errorMessage); window.onerror = window.onerrorSave; return true; } function getApp(name,notShowMessage) { window.errorMessage = null; var a = "Error while accessing applet information for the \"" + name + "\" Java applet."; var b = "Maybe, this applet is not correctly loaded.Please try to reload this page."; if (notShowMessage==null || !notShowMessage) { window.errorMessage = a + b; } window.onerrorSave = window.onerror; window.onerror = showMyErrorMessage; var app = eval("document."+name); var appInfo = app == null? null: app.getAppletInfo(); window.onerror = onerrorSave; if (app == null || appInfo == null) { if (window.errorMessage != null) { if (app == null) alert("Cannot access \"" + name + "\" Java applet." + b); else alert("Cannot access applet information for the \"" + name + "\" Java applet." + b); } return null; } return app; }
Используется достаточно древняя (по идее, кросс-броузерная) техника подавления сообщения об ошибках через window.onerror. Все работает под Mozilla 1.4, MSIE 6.0 и даже под древним Netscape 4.5, но, увы, не под (куда более популярной) Opera 7.23: последняя выдает сообщение об ошибке JavaScript. Обращение к некоторому методу апплета необходимо - ибо почти все броузеры (кроме Netscape) успешно возвращают ненулевой объект document.ИмяАпплета, как только в странице прочитан ТЭГ
Из прочих методов проверки всевозможные onload у меня вызывают недоверие - в свое время (на старых броузерах) мне часто приходилось отлаживать ситуации, когда onload без видимых причин отказывался срабатывать, например при нажатии Refresh для страницы или чего-нибудь подобного. Самым надежным кажется "активное" информирование страницы - когда Java-код апплета обращается к JavaScript. Но тут вроде бы единственное кросс-броузерное решение - showDocument в отдельное окно (или фрейм), что делает решение крайне громоздким.
Может быть, кто-нибудь подскажет надежный, желательно опубликованный и широко известный способ проверки загруженности апплета?
Для Opera, кстати, нормально работает конструкция try...catch. Но только эта же конструкция, если не ошибаюсь, приведет к ошибке синтаксиса в ранних MSIE , которые до сих пор, кажется, превосходят Opera по популярности. Как бы надежно удостовериться, что можно использовать try...catch? Условная компиляция MSIE -
/*@cc_on @*/ /*@if (@_jscript_version >= 5) (испольщуем здесь try..catch и другие хорошие вещи) @*/ /*@end @*/
Как водится, в Opera игнорируется:(
Надо полагать, имеется в виду пакет netscape.javascript.* ?
Это решение непереносимо - если не ошибаюсь, в MSIE со встроенным JRE 1.1.4 эта техника начала работать только где-то с версии 5.5 или даже выше. Я этим пакетом никогда не пользовался - по причине непереносимости; может быть, я не прав? Я писал про это выше: "тут вроде бы единственное кросс-броузерное решение - showDocument в отдельное окно (или фрейм), что делает решение крайне громоздким".
Апплеты я обычно компилирую в JDK 1.1.6 (самая ранняя версия, имеющаяся в архивах Sun); там этого пакета вовсе нет.
А если городить огород, учитывающий, что пакета netscape.javascript.* может не быть, то получится ничуть не лучше, чем, к примеру, отдельно проверять оперу и использовать для нее try...catch.
Давно дело было:) Варианты:
public void init() {
//....
getAppletContext().showDocument("js_page.htm", "another_frame");
}
Пример 1998 года - http://www.copris.com/optocontrol/home.htm - в IE5.5 и Мозилла 1.6 работает (делалось во времена NN3 и IE3) :)
function checkApplet() {
if (document && document["appletName"] && document["appletName"].isActive())
//Do something
else
setTimeout(checkApplet, 100);
}
isActive() - это метод класса java.applet.Applet.
Алексей Рюмин aka Dwarf[досье]
Спасибо большое. Но...
У меня, увы, страница по природе не фреймовая, и вводить туда фреймы только ради апплета очень неудобно. А вариант с IFRAME не кросс-броузерный - это будет ничем не лучше моего решения с window.onerror.
Собственно, уже сейчас мои апплеты с 3D-структурами присутствуют на нескольких наших страницах, а в будущем таких страниц будет гораздо больше (всевозможные галереи примеров структур и т.п.). Собственно, на нашем сайте апплеты будут занимать примерно то же место, что и картинки (): иллюстрация к тексту, которую можно заодно "покрутить" мышкой. И возле каждого такого апплета, возможно, будут некоторые простейшие управляющие JavaScript-кнопки: ну хотя бы для разворота повернутой трехмерной картинки в исходную позицию.
Отсюда - необходимость универсальной функции вроде моей getApp, которую можно положить в подключаемый js-файл и ради которой не надо перекраивать сайты на фреймы.
Пишем простой тест.
... alert(document.XXXX+""+document.XXXX.isActive());
После чего грузим эту страницу через любой не-мгновенный Internet, почистив предварительно кэш MSIE . Как и следовало ожидать, пока апплет реально не загрузился (серый квадрат), вызов isActive() порождает вышеупомянутое сообщение об ошибке. В то же время, обращение document.XXXX срабатывает нормально, в чем можно убедиться, изменив код на
alert(document.XXXX);
Раз объект страницы XXXX был уже отрендерен, броузер разрешает свободно обращаться к этому объекту.
Правда, тут выплывает один интересный нюанс. При превращении объекта-апплета в строку получаются разные результаты, в зависимости от того, загрузился апплет или еще нет. Именно, если апплет загружен, то преобразование DHTML -объекта в строку дает результат вызова "toString()" у апплета. По идее, написать бы в методе toString некое ключевое слово и проверять, присутствует ли это слово в строке document.имяапплета+"".
Было бы просто замечательно, очень просто и красиво, и даже в Opera работает. Но - УВЫ - на этот раз подкачала Mozilla. Показывает, зараза, дурацкое независимо от факта загрузки. Так что - не пойдет...
Пока что - подскажите, как надежно "обнаружить", что мы имеем дело с современной Opera - точнее, что работают try...catch? Opera, кажется, имеет обыкновение прикидываться другими броузерами. Если выяснить, что try..catch работают, можно бы вызвать через eval версию кода с этими операторами - она работает и под Opera.
Еще в эту же тему. Предлагаю разделить возможные решения проблемы на две группы.
Если можно, прошу ограничиться решениями второго типа.
Что-то вы не понимаете, уважаемые.
Нельзя ЯВНО вызывать toString()! У DHTML -объекта "апплет" НЕТ собственного метода toString, он появляется, только когда загрузится Java-класс. Соответственно, попытка вывести
alert(document.PackingSpheresForDesign.toString());
при незагруженном апплете приводит к ошибке JavaScript, в моем MSIE это "Unspecified error".
Неявно вызвать toString, разумеется, можно всегда - преобразованием DHTML-объекта в строку. И здесь, как я уже говорил, Mozilla ведет себя некрасиво: никогда не вызывает toString() апплета, даже когда апплет полностью загружен. Да и не документировано нигде, что броузер обязан использовать toString Java-класса. Решение, опирающееся на проверку строчного представления DHTML-объекта Applet, очевидным образом попадает в первую категорию: если некий броузер не захочет вызывать метод toString, то на таком броузере апплет ВСЕГДА будет считаться незагруженным, и пользователь вообще не сможет работать.
Как все-таки удостовериться в JavaScript, что броузер достаточно хорош, чтобы понять конструкцию try...catch? Я пока склоняюсь пойти по этому пути.
Даниэль Алиевский[досье]
Не, ну понятно, что в MSIE вызов toString() ошибка, но браузер-то в javascript легко определить. Если браузер mozilla, вызывайте toString(), если нет, просто applet.
Что касается вызова метода toString в браузере, то насколько я понимаю у любого объекта в javascript должен быть метод toString и если браузер не вызывает этот метод у апплета, тогда имеются сомнения в том, что в этом браузере вообще возможно вызывать методы апплета - безотносительно к поведению в данном случае mozilla.
Короче, надо сначала найти такой браузер и желательно чтобы он был достаточно распространен, ибо в противном случае я сам в состоянии достаточно быстро написать браузер, который бы саботировал все попытки определения загруженности апплета.
Ну да. Я просто не додумал. Действительно, надо просто в моей функции обратиться не к методу getAppletInfo, а к методу toString. В MSIE , правда, как и раньше, будет ошибка, но она благополучно ловится через window.onerror. Зато в Opera - и во всех броузерах, которые разрешают вызывать toString у недозагруженного апплета - никаких ошибок вообще не будет, просто toString вернет либо строку с кодовым словом, если апплет загружен, либо нечто умолчательное. При этом, вроде бы, не должно быть настолько странного броузера, чтобы у нормально загруженного апплета JavaScript-вызов toString не обратился бы к одноименному методу апплета.
Кажется, найдено неплохое решение. Спасибо за помощь. Дотестирую его под всякими кривыми броузерами вроде Netscape 3 - и предложу для FAQ .
Александр Самойлов[досье] "Что касается вызова метода toString в браузере, то насколько я понимаю у любого объекта в javascript должен быть метод toString и если браузер не вызывает этот метод у апплета, тогда имеются сомнения в том, что в этом браузере вообще возможно вызывать методы апплета..." - тут я не совсем вас понял, ведь как раз самый популярный MSIE считает, что никакого toString у объекта Applet нет, если апплет не загружен (к примеру, если указан неверный путь к классу). Я вообще не видел внятных указаний в документации, что КАЖДЫЙ JavaScript объект обязан обладать таким методом. Если таковые есть - ткните пальцем, если не трудно.
цитата из справки для JScript
The Object object is contained in all other JScript objects; all of its methods and properties are available in all other objects. The methods can be redefined in user-defined objects, and are called by JScript at appropriate times. The toString method is an example of a frequently redefined Object method.из нее, конечно нельзя однозначно сделать вывода, о том, что и для всех других интерпретаторов javascript подобное выполняется.
что касается MSIE , то он не считает, что у апплета нет метода toString, он считает, что произошла неопределенная ошибка во время выполнения этого метода.
например, если попытаться вызвать заведомо несуществующий метод у апплета то ошибка будет другой.
Черт! Вы будете смеяться, но MSIE + Java 2 ВООБЩЕ не желает вызывать toString() у НОРМАЛЬНО загруженного апплета. Устойчиво выдает Unspecified error. А при умолчательном преобразовании в строку, соответственно, мой перекрытый toString попросту игнорируется.
Может быть, конечно, у меня что-то не то с апплетом - надо бы, по идее, сделать чистый тест. Но в любом случае - если хотя бы на моем апплете это так, значит технология неверная.
Что б его. Вчера забыл проверить на этой ситуации (проверял под Java 1.1.4). Сегодня полчаса убил на таинственный глюк страницы. Хуже того, в качестве "побочного эффекта" MSIE принялся глухо зависать при открытии страницы (видимо, из-за разных моих вспомогательных скриптов). Ужасно.
Вернулся к старой методике с вызовом getAppletInfo().
Так что, господа, жду дальнейших предложений. В частности - как отловить Оперу (чтобы бороться с ней отдельно).
Владимир Палант[досье] Спасибо. Можно первоисточнк, если не затруднит? (Догадываюсь, что где-то на сайте opera.)
Мне бы хотелось не столько обнаружить Оперу, сколько проверить версию JavaScript, что он поддерживает try...catch - совместимым с Opera способом. Микрософтоский вариант такой проверки - условная компиляция - естественно, под Opera не работает.
На худой конец достаточно и проверки Оперы: в этом случае можно (надеюсь:-)) смело вызывать toString у апплета.
Даниэль Алиевский[досье]
а почему бы не использовать версию яваскрипт для отлова поддержки try catch
var try_catch = false
try_catch=true
if (try_catch) {}
правда в опере не проверял
Даниэль Алиевский[досье]
Нет, на opera.com рекомендуют проверять по User-Agent (http://www.opera.com/support/search/supsearch.dml?index=570) — ИМХО извращение. Проверять по window.opera надежней — никакой другой браузер это свойство поддерживать не станет.
Opera поддерживает try/catch как минимум с версии 4.0, так что можете считать, что поддерживает всегда.
Есть еще одна идея - пока не проверил. Обращение к свойствам DHTML -объекта (property), насколько я знаю, никогда не порождает исключений. Если такого свойства нет, просто возвращается null. Хорошо бы снабдить апплет неким свойством (к примеру, boolean iAmLoaded=true), и проверять, установлено ли оно. Насколько я понимаю, в случае Java 2 это не так просто - недостаточно завести public-поле, нужно объявлять пару методов get/set, как это полагается в JavaBeans (пока еще не изучил соответствующую документацию).
Как считаете, насколько это надежная и кросс-броузерная техника?
Не понял я, при чем тут JavaBeans, по-моему доступ к свойствам осуществляется без всяких get/set. Но в любом случае — проверять можно наличие метода, который для DHTML тоже свойство: if (typeof(applet.notifyAll) != "undefined") . А вот кроссбраузерность вам уже придётся самим проверить...
Владимир Палант[досье]
Намек на JavaBeans Introspection есть вот здесь: http://java.sun.com/j2se/1.4.2......loper_guide/compatibility.html
Как я понял, проблема имела временный характер: у меня на компьютере во всех броузерах и JRE доступ к public-полю чудесно работает. Причем совершенно нетрудно добавить в апплет "настоящее" public-поле типа boolean, тогда не потребуется прибегать к более экзотическим приемам типа typeof(applet.notifyAll). (Кстати, упомянутый typeof не работает у меня в MSIE ни с 1.1.4, ни с Java 2.)
Проблема в том, что раньше я применял как раз такую технику - проверку существования public-поля - и однажды столкнулся с проблемой, причем, очевидно, того самого неприятного первого типа: поле не обнаруживалось, апплет детектировался как незагруженный и начисто отказывался работать. Это произошло на 2 "чужих" компьютерах с вполне нормальной конфигурацией (MSIE + Java 2, что-то типа JRE 1.4.2_01), хотя на моем компьютере все работало. Естественно, я перестал пользоваться проверкой поля - от греха подальше.
Но, может быть, я просто сделал все недостаточно грамотно? Скажем, не объявил методов get/set "по-JavaBean-овски"? Если я не увижу в документации четкого описания этой проблемы с объяснением, почему на некоторых броузерах доступ к обычному public-полю не работает, и указанием, как делать это корректно, я, конечно, не рискну применять проверку поля - слишком высока цена ошибки.
Перехват сообщения об ошибке, как выяснилось, работает даже под Netscape 3. Но - немного не так, как нужно: этот древний броузер вызывает процедуру показа сообщения асинхронно с общим потоком JavaScript-кода, что приводит к тонким ошибкам. Пока не доотладил. Естественно, совместимость с Netscape 3 никому не нужна, но настораживает, что методика (обращение к методу апплета, или toString для Оперы, с перехватом ошибки) требует отладки "по новой" чуть ли не для каждого класса броузеров:(Видимо, все-таки техника кривая. А какая техника "прямая" - пока непонятно.
С Netscape 3.0 песня оказалась совсем в другом. Этот броузер вообще не сильно дружил с обращениями типа document.xxxx, где xxxx - имя апплета. Даже для реально загруженного апплета он имел обыкновение при таком обращении выдавать целую пачку ошибок:
Can"t reflect applet "(null)": not loaded yet
(Самое смешное, что это происходит и при проверках типа "if (document.getElementById != null)...".) Борьба с этим очень проста. Достаточно каждое обращение к любому document.xxxx обрамлять кодом наподобие:
var onerrorSaveLocal = window.onerror;
window.onerror = null; // - avoiding an incorrect exception in Netscape Navigator 3
var v = document.xxxx;
window.onerror = onerrorSaveLocal;
При этом, как и в Netscape 4, и во встроенном "броузере" из JavaBuilder, при недозагруженном апплете document.имяАпплета просто возврашает null.
В общем, я потратил некоторое время и отладил свою процедуру под всеми броузерами, до которых смог "дотянуться" - включая предыдущие версии MSIE . Вот что получилось:
Function showMyErrorMessage(msg,url,line) { if (window.errorMessageA != null) alert(window.errorMessageA+"(System error message: "+msg+")"+window.errorMessageB); window.onerror = window.onerrorSave; return true; } function getApp(name,notShowMessage) { // For compatibility with this function, all Java applets must override "toString()" method // and return a string containing "Successfully loaded Java applet" substring as it"s result. window.errorMessageA = window.errorMessageB = null; if (notShowMessage==null || !notShowMessage) { window.errorMessageA = "Error while accessing applet information for the \"" + name + "\" Java applet."; window.errorMessageB = "Maybe, this applet is not correctly loaded." + "Please wait until it will be completely loaded, " + "or please try to reload this page."; } var opera = window.opera != null; if (window.onerrorSave == null) window.onerrorSave = window.onerror; var app = null; var appInfo = null; var onerrorSaveLocal = window.onerror; window.onerror = null; // - avoiding an incorrect exception in Netscape Navigator 3 // ("Can"t reflect applet "(null)": not loaded yet") // sometimes appeared while accessing correctly loaded applets app = eval("document."+name); window.onerror = onerrorSaveLocal; var systemErrorMessage = null; /*@cc_on@*/ /*@if (@_jscript_version >= 5) try { // some MSIE (for example, MSIE 5.0) don"t understand onerror-based catching @else @*/ window.onerror = showMyErrorMessage; // catching exceptions while calling non-existing method /*@end @*/ appInfo = app == null? null: // a case of Netscape browser opera? app.toString(): // MSIE + Java2 cannot call applet"s toString app.getAppletInfo(); // MSIE and Mozilla (but not Opera) will catch an exception here /*@if (@_jscript_version >= 5) } catch(e) { systemErrorMessage = e==null || e.description==null? "unknown error": e.description+""; } @else @*/ window.onerror = window.onerrorSave; window.onerrorSave = null; /*@end @*/ if (app == null || systemErrorMessage != null || appInfo == null || (opera && (appInfo+"").indexOf("Successfully loaded Java applet")==-1)) { if (window.errorMessageA != null) { if (app == null) alert("Cannot find \"" + name + "\" Java applet." + window.errorMessageB); else if (systemErrorMessage != null) alert("An exception occured while accessing applet information for the \"" + name + "\" Java applet. (System exception information: " + systemErrorMessage + ")" + window.errorMessageB); else if (appInfo == null) alert("Cannot access applet information for the \"" + name + "\" Java applet." + window.errorMessageB); else alert("Cannot call \"" + name + "\" Java applet." + window.errorMessageB); } return null; } return app; }
Как водится, MSIE доставили максимум проблем. Из относящихся к делу: MSIE 5.0, как выяснилось, отказывается блокировать сообщения об ошибках через window.onerror. Пришлось специально для "капризного" MSIE написать ветку c условной компиляцией и try..catch. На первый взгляд, try..catch - самое надежное решение, так что вполне логично применять его в самом популярном семействе броузеров. При этом в MSIE 4 (где нет try..catch), а также в Mozilla продолжает работать блокировка ошибки через window.onerror. В Opera используется вызов toString и проверка "кодового слова" внутри результата. Еще попутно выяснилось, что в MSIE 4 лучше не пытаться обращаться к апплету из onbeforeunload - могут быть ошибки.
Я дошел даже до MSIE 3.0:-) Там, кажется, моя процедура не сработала, хотя, возможно, дело тут в том, что мои классы скомпилированы несовместимым с Java 1.0.2 способом, а поддерживать подобную совместимость у меня нет ни малейшего желания.
Теперь у меня есть огромная просьба ко всем присутствующим. Пожалуйста, протестируйте эту процедуру с каким-нибудь апплетом на всех своих броузерах. Например, работает ли это в Unix Mozilla/Opera, или на Macintosh? Вo всех ли вариантах Windows+MSIE? Что насчет более ранних версий Opera?
Я протестировал в следующих броузерах:
Windows XP: MSIE 6.0 c Java 1.4.2 и Java 1.1.4, Mozilla 1.4, Opera 7.23, Netscape 4.5, Netscape Navigator 3.0;
Windows NT 4.0: MSIE 5.0 с Java 1.4 и Java 1.1.4, Netscape 4.5, Netscape Navigator 3.0;
Windows-95: MSIE 3.0 (Java 1.0.2), Netscape 4.5.
Тестировать проще всего, указывая на странице заведомо неправильный путь к апплету (и, для сравнения, правильный) - по-моему, это достаточно похоже на ситуацию, когда апплет не догрузился. Если все нормально, то, по идее, процедура заслуживает помещения в FAQ .
На этой странице кнопка "Get JVM information" (использующая вышеописанную функцию) должна срабатывать, как только апплет загрузится, либо "ругаться", пока он не загружен.
(Кстати, в MSIE 3.0 эта техника таки не работает - в моей версии 3.02 JavaScript вообще отказывается что-либо делать, если апплет не загружен. И бог с ним.)
Этот раздел касается:- Платформы: Все платформы
- Версии Java: 7.0, 8.0
При запуске апплета или приложения Java появляется диалоговое окно с предупреждением системы безопасности:
Заблокировать запуск потенциально небезопасных компонентов?
Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности. Свяжитесь с поставщиком приложения и убедитесь в отсутствии попыток несанкционированного доступа.
ПРИЧИНА
Подписанные приложения и апплеты Java Web Start, содержащие подписанные и неподписанные компоненты, могут быть потенциально небезопасными, если смешанный код не был намеренно использован поставщиком приложения. Начиная с выпуска Java SE 6 Update 19 при работе с программой, которая содержит подписанные и неподписанные компоненты, отображается диалоговое окно с предупреждением.
РЕШЕНИЕ
Если в диалоговом окне безопасности нажать кнопку Да
, запуск потенциально небезопасных компонентов будет заблокирован, после чего возможно завершение работы программы. Если нажать кнопку Нет
, выполнение приложения или апплета продолжится.
Предупреждение отображается по умолчанию, но существуют параметры для изменения этой настройки.
Способ обработки программ со смешанным кодом можно настроить с помощью панели управления Java.
Поиск панели управления Java Параметры защиты от смешанного кода в панели управления Java
ДОПОЛНИТЕЛЬНАЯ ТЕХНИЧЕСКАЯ ИНФОРМАЦИЯ
Для разработчиков Java-приложений: см.
