Установка java-апплета для системы «банк-клиент онлайн. Ошибка
Проблема в следующем.
На странице размещен некоторый апплет, а также интерфейс для управления им, написанный на 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 апплет не загружен. На протяжении более чем десятилетия существовало большое количество веб-технологий. Так, например, для мультимедиа и простых игр использовался Flash, а для проведения операций, предъявляющих высокие требования к безопасности – ActiveX и Java. Но если разработанная Microsoft ActiveX уже давно канула в лету, то Java EE продолжает быть актуальной до сих пор. И дело не в том, что не существует достойных и более простых для конечного пользователя аналогов (они-то как раз появились несколько лет назад), проблема в том, что некоторые организации вложили десятки и сотни тысяч долларов в разработку приложений на основании этих технологий, и они просто так не могут от них отказаться. Именно поэтому, пользователи при попытке войти в определенный сервис могут видеть сообщение: Java апплет не загружен, что делать если вы повстречали его мы как раз и рассмотрим ниже.
У некоторых клиентов ВТБ24 при попытки зайти в ВТБ24 онлайн возникает ошибка. Она как раз связана с тем, что Java апплет либо не установлен в системе, либо он отключен.
Чтобы исправить эту ошибку с загрузкой Java и без проблем войти в панель управления счетом потребуется выполнить ряд простых действий.
Что делать, если Java апплет не загружен
В первую очередь потребуется установить само программное обеспечение. Если оно загружено, но не включено, все равно скачайте – пусть будет установлена самая свежая версия. Для этого:
Следует отметить, что в Google Chrome (начиная с 42-й версии) апплет Java официально не поддерживается, так как корпорация считает соответствующую технологию устаревшей. Поэтому, чтобы воспользоваться Java запустите другой веб-браузер, например, FireFox.
Чтобы проблем с Java не возникало, выполните следующие действия:
После выполнения указанных действий заходите на интересующий вас сайт – весь его функционал (конечно, если он не использует других сторонних технологий) будет работать, а ошибки с загрузкой Java апплет не возникнет.
Можно ли обойтись без JavaЕсли у вас нет необходимости использовать веб-приложения (как в случае в банковским клиентом ВТБ24), созданные на основании Java EE, тогда соответствующий апплет вам ни к чему. Постепенно даже крупные компании переходят на более актуальные сейчас для веб-а технологии, делая взаимодействие с функциями их сервисов намного проще для конечного пользователя.
Вконтакте
Много-много лет назад, работая админом на одном из градообразующих предприятий российской глубинки, мне пришлось впервые столкнуться с понятием «электронно-цифровая подпись» (далее ЭЦП).
В головах руководства, на тот момент, укоренилась мысль, что ЭЦП - это обычная подпись, отсканированная и добавляемая на все документы, которые должны быть «подписаны».
Давайте разбёрмся, что же такое ЭЦП и как она работает.
Для работы с ЭЦП нам, прежде всего, необходим цифровой сертификат и закрытый ключ.
Сначала, нам необходимо установить ЭЦП под документом.
Установка ЭЦП происходит в два шага:
1. Берём документ, который мы хотим подписать и вычисляем хэш от этого документа. (Упрощённо, хэш - это односторонняя математическая функция преобразования документа произвольной длинны, в документ фиксированной длинны).
2. Затем, этот полученный хэш шифруем нашим закрытым ключом. 
Теперь документ, с прикреплённой к нему ЭЦП и нашим сертификатом, отправляем получателям.
Получив подписанный документ, нам необходимо проверить подпись - действительна она или нет.
Проверка ЭЦП происходит несколько сложнее:
1. Берём документ, подпись под которым необходимо проверить, вычисляем хэш от этого документа.
2. Берём цифровой сертификат пользователя, который подписал документ и прикреплённую к документу ЭЦП (которая является зашифрованым на закрытом ключе подписсанда хэшом оригинального документа) и расшифровываем с помощью открытого ключа.
Таким образом, у нас есть два хэша - тот, который мы вычислили сами и тот, который мы получили вместе с документом и расшифровали открытым ключом подписанта.
3. Теперь сравниываем эти хэши. Если хэши совпадают, значит подпись действительна, если хэши различаются, значит подпись неделйствительна.
В заключении определим, что нам даёт использование цифровой подписи:
1. Неизменяемость в процессе передачи или хранения - если документ был изменён, то хэш, который мы вычислим, и который был прикрёплён к документу, буду разные, следовательно, подпись будет неделйстительная, из чего можно сделать вывод, что документ был изменён;
2.
Для того, чтобы было невозможно подделать ЭЦП, закрытый ключ должен быть в единственном экземпляре и доступ к нему должен быть только у владельца. Это можно реализовать используя смарт-карты, но это уже совсем другая история.
Вслед за стремительным развитием информации ВТБ, как и многие другие банки, стал внедрять функцию под названием «дистанционное банковское обслуживание». С этой целью специалистами ВТБ был создан специальный апплет – программа, через которую клиенты и получают доступ к своим счетам. Чаще всего, как и в этом случае, для этих целей используют язык программирования Java (произносится «джава» или «ява»). Чтобы начать пользоваться программой от ВТБ, необходимо скачать программу, установить и настроить ее.
Для чего нужен Java-апплет?Такой апплет работает, основываясь на трех китах. Их имена: Надежность, Производительность и Безопасность. Так что не удивительно, что апплеты на этой платформе используют не только финансовые организации вроде ВТБ, но и бухгалтерские отделы, научные предприятия, а также производители технической продукции для бытовых и коммерческих потребностей. Возможности платформы многогранны:
- простой способ сформировать и настроить сетевое приложение;
- доступность работы с базами данных;
- детальная проработка уникальных сценариев развития событий;
- возможность выбирать параметры фильтра на вводе и выводе;
- доступ к интернет-службам;
- автоматическое управление памятью;
- полноценная работа с форумами, онлайн-магазинами, опросниками, играми и приложениями в сети;
- одновременно выполняется несколько программ на любом из указанных языков;
- поддержка многопоточных приложений;
- возможные сообщения и ошибки, если он не загружен;
- различные классы для выполнения HTTP-запросов и обработки ответов.
Описанные преимущества делают платформу Java идеальной для ВТБ апплета.
Возможные ошибкиНиже собраны самые распространенные ошибки, с которыми сталкиваются клиенты ВТБ после установки апплета, и способы их устранения.
Апплет не запускается после обновления до Java 7 Update 65Эта проблема чаще всего касается обладателей Windows 7, 8 и 10, с версиями Java 7.0 или 8.0. Суть проблемы сводится к тому, что апплет ВТБ перестал запускаться. Причина кроется в отсутствии строки deployment.javaws.jre.0.args= в документе с именем deployment.properties. Разработчики устранили неполадки в Java 7 Update 67 (7u67), поэтому для большинства, решение проблемы – установка последней версии ПО. Загрузить программу можно по ссылке: https://www.java.com/ru/download/ . Главная страница выглядит так: 
В случае, когда обновление невозможно, существуют другие варианты. Конечным пользователям версии 7u65 стоит немного изменить параметры Java Control Panel. Сделать это можно следующим образом:
Следуя этому руководству любой может настроить свой апплет ВТБ довольно быстро.
Временно решить проблему можно, внеся поправки в код:
Так вы заставите апплет ВТБ работать и проблема с обновлением будет решена.
Апплет ВТБ не загруженВажная предыстория: из множества технологий, которыми пользовались компании, некоторые безнадежно устарели и уже не в состоянии выполнять свои функции как положено. Однако хозяевам больших предприятий очень жаль потраченных десятков/сотен тысяч долларов на разработку корпоративных приложений на основе упомянутых технологий. В связи с этим, некоторые клиенты, заходя в сервис, могут видеть ошибку с вышеуказанным названием.
Это касается и некоторых клиентов ВТБ: при попытке зайти в систему удаленного управления счетами отображается описанная ошибка апплета. Причиной может быть отсутствие апплета или его нерабочее состояние. Однако с этим легко справиться, достаточно последовать простым указаниям ниже.
Легче всего для начала установить апплет ВТБ с официального сайта Java. Сделать это стоит даже тогда, когда программное обеспечение у вас уже есть, но не включено: будет лучше, если на вашем компьютере будет установлена самая актуальная версия программы. Итак, следуйте указаниям:
Важная информация: начиная с 42-й версии Google Chrome официально не поддерживает апплеты на базе Java, в том числе апплет ВТБ.
Однако он доступен в любом другом браузере, к примеру, Mozilla Firefox. Включить апплет там можно следующим образом:
После этих нехитрых манипуляций можете свободно заходить на сервис ВТБ: апплет должен работать без перебоев.
Установка апплета ВТБЧтобы установить и настроить апплет ВТБ скачайте его по ссылке http://www.java.com⁄ru⁄ . Апплет подойдет под функционалы таких браузеров как FireFox, Opera, Internet Explorer (версия которого должна постоянно обновляться).
Апплет для работы с ВТБ устанавливается в две стадии:
- установка и настройка платформы SE Runtime Environment;
- установка самого апплета.
Если для доступа вы планируете использовать персональный компьютер, первый шаг вам не нужен. Порядок установки состоит из пяти пунктов:
Затем скрипт нужно настроить:
«Пуск» =› контрольная панель =› убрать галочки с протоколов TLS 1.1, TLS 1.2 и «Use SSL 2.0 compatible ClientHello format». Теперь вы имеете свободный доступ к апплету ВТБ.
Настройка браузеровОкно-предупреждение с сообщением «Внимание. Java апплет не загружен» может возникать по причине браузеров. Чтобы настроить их на взаимодействие с апплетом ВТБ, следуйте инструкциям в таблице ниже.
| Firefox | 1. Нажмите на иконку. |
| 2. В выпадающем меню выберите статус «Разрешить и запомнить». | |
| 3. Нажмите «ОК». | |
| 4. Зайдите в настройки браузера. | |
| 5. Выберите пункт «Дополнения», подпункт «Плагины». | |
| 6. Проставьте по всем подпунктам Java статус «Включать по запросу». | |
| Opera | 1. Откройте настройки браузера. |
| 2. В пункте «Плагины» (рекомендуется)» выберите «Запускать все содержимое плагинов». | |
| Safari | 1. На странице регистрации в системе ВТБ выберите меню «Safari» => «Настройки» => «Безопасность» => «Настроить веб-сайт». |
| 2. В левом списке диалога выберите «Java». В правом списке для сайта ВТБ задайте режим «Вкл.». | |
| 3. Нажмите и удерживайте ALT переводя курсор мыши ВКЛ. Затем нажмите кнопку мыши. Появиться выпадающее меню, в котором выбрать «Запустить в безопасном режиме». | |
| 4. Нажмите «Готово» и перезагрузите браузер. | |
| Internet Explorer | 1. В настройках браузера выберите «Сервис» => «Свойства обозревателя» => «Дополнительно». Снимите отметку SSL 2.0 и отключите использование протоколов TLS 1.1 и 1.2. |
| 2. В настройках браузера выберите «Настроить надстройки». | |
| 3. В появившемся окне выберите «Запуск без получения разрешения». | |
| 4. В списке надстроек найдите «Java Plug-in ». Состояние данной надстройки должно быть «Включено». |
Итак, апплет от ВТБ – штука очень полезная, поэтому важно знать, как правильно установить программное обеспечение для него. Для тех, кто любит наглядные демонстрации, посмотрите видео.