Installing a java applet for the online bank-client system. Error
The problem is this.
The page contains an applet, as well as an interface for managing it, written in HTML + JavaScript. You need to determine from JavaScript that the applet is loaded and ready to go. The solution must be EXTREMELY reliable - cross-browser, responsive to slow Internet, etc.
I am commenting. Until the applet has loaded, calls from JavaScript to its public methods and/or fields are fraught with the appearance of a very ugly message with the following content: “This method is missing.” And the applet sometimes takes much longer to load than the page itself. Moreover, sometimes it makes sense to do some things automatically (from JavaScript) as soon as the applet is loaded - say, give it some command.
The problem here is not so much that there is no way to check that the applet has already loaded, but that there are an abundance of such methods. For example: onload of an applet, onload of a page, calling a method or field of an applet, “actively” informing the page that the applet is loaded with special Java code from within the applet itself, etc. And the confidence that these methods will work:
on every imaginable browser,
in front of everyone Security settings in browsers,
combined with all imaginable platforms,
with all JREs,
I have no. And getting such confidence is almost impossible: there are too many combinations.
Worse, it seems very easy to "overthink" here. For example, yesterday I “struggled” with an error for a long time - on someone else’s computer (XP+ MSIE + Java2), JavaScript mistakenly assumed that the applet was not loaded, although everything was fine on my computer. I suspect the fact is that I then used access to a certain public variable of the applet (not a method!) to check availability. All browsers on my computer (also XP) return null when accessing such a variable of an underloaded applet, and as soon as the applet is loaded, they return its value. (In contrast, calling a method on an underloaded applet produces an error.) I'm afraid that on someone else's computer the browser refused to read the public variable. Access to variables is generally a non-obvious thing that works differently under different browsers and JREs. Only calling methods is reliable, but only when the applet is loaded.
So far I've written the following couple of functions:
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; )
We use a fairly ancient (in theory, cross-browser) technique for suppressing error messages via window.onerror. Everything works under Mozilla 1.4, MSIE 6.0 and even under the ancient Netscape 4.5, but, alas, not under (much more popular) Opera 7.23: the latter produces a JavaScript error message. Calling some applet method is necessary - because almost all browsers (except Netscape) successfully return a non-null document.AppletName object as soon as the TAG is read in the page
Among other verification methods, all kinds of onload cause me distrust - at one time (on old browsers) I often had to debug situations when onload without visible reasons refused to fire, for example when pressing Refresh for a page or something similar. The most reliable seems to be "active" informing the page - when the applet's Java code accesses JavaScript. But here it seems that the only cross-browser solution is showDocument in separate window(or frame), which makes the solution extremely cumbersome.
Maybe someone can suggest a reliable, preferably published and well-known way to check whether an applet is loaded?
For Opera, by the way, the try...catch construct works fine. But only this same construction, if I'm not mistaken, will lead to a syntax error in early MSIE, which still seems to surpass Opera in popularity. How can I reliably make sure that try...catch can be used? MSIE conditional compilation -
/*@cc_on @*/ /*@if (@_jscript_version >= 5) (use try..catch and other good things here) @*/ /*@end @*/
As usual, it is ignored in Opera :(
I assume you mean the netscape.javascript.* package?
This solution is not portable - if I'm not mistaken, in MSIE with built-in JRE 1.1.4 this technique only started working somewhere around version 5.5 or even higher. I have never used this package - due to intolerance; maybe I'm wrong? I wrote about this above: “here it seems that the only cross-browser solution is showDocument in a separate window (or frame), which makes the solution extremely cumbersome.”
I usually compile applets in JDK 1.1.6 (the earliest version available in the Sun archives); This package is not there at all.
And if you fence the garden, taking into account that the netscape.javascript.* package may not exist, then it will turn out no better than, for example, checking the opera separately and using try...catch for it.
It's been a long time coming :) Options:
public void init() (
//....
getAppletContext().showDocument("js_page.htm", "another_frame");
}
An example from 1998 - http://www.copris.com/optocontrol/home.htm - works in IE5.5 and Mozilla 1.6 (done in the days of NN3 and IE3) :)
function checkApplet() (
if (document && document["appletName"] && document["appletName"].isActive())
//Do something
else
setTimeout(checkApplet, 100);
}
isActive() is a method in class java.applet.Applet.
Alexey Ryumin aka Dwarf[dossier]
Thanks a lot. But...
Unfortunately, my page is not frame-based by nature, and introducing frames there just for the sake of an applet is very inconvenient. And the option with IFRAME is not cross-browser - it will be no better than my solution with window.onerror.
Actually, my applets with 3D structures are already present on several of our pages, and in the future there will be many more such pages (all kinds of galleries of example structures, etc.). Actually, on our website applets will occupy approximately the same space as pictures ( ): an illustration for the text, which can also be “twirled” with the mouse. And next to each such applet there will probably be some simple JavaScript control buttons: well, at least for rotating a rotated three-dimensional image to its original position.
Hence the need for a universal function like my getApp, which can be placed in an included js file and for which there is no need to convert sites into frames.
Let's write a simple test.
... alert(document.XXXX+""+document.XXXX.isActive());
Then we load this page through any non-instant Internet, having first cleared the MSIE cache. As you might expect, until the applet has actually loaded (the gray square), the isActive() call generates the above error message. At the same time, calling document.XXXX works normally, as you can verify by changing the code to
alert(document.XXXX);
Since the page object XXXX has already been rendered, the browser allows free access to this object.
True, one interesting nuance emerges here. Turning an applet object into a string produces different results depending on whether the applet has loaded or not yet. Namely, if the applet is loaded, then converting the DHTML object to a string gives the result of calling “toString()” on the applet. In theory, I would write a certain keyword in the toString method and check whether this word is present in the line document.appletname+"".
It would be just wonderful, very simple and beautiful, and even works in Opera. But - Alas - this time Mozilla let us down. Shows infection, stupid, regardless of the fact of loading. So it won't work...
For now - tell me how to reliably “detect” that we are dealing with modern Opera - more precisely, that try...catch works? Opera seems to have a habit of pretending to be other browsers. If you find out that try..catch works, you could call the version of the code with these operators via eval - it also works under Opera.
More on the same topic. I suggest sharing possible solutions problems into two groups.
If possible, please limit yourself to solutions of the second type.
There is something you don’t understand, dear ones.
You can't EXPLICITLY call toString()! The DHTML applet object does NOT have its own toString method; it only appears when the Java class is loaded. Accordingly, an attempt to derive
alert(document.PackingSpheresForDesign.toString());
when the applet is not loaded, it results in a JavaScript error, in my MSIE it is "Unspecified error".
Of course, you can always call toString implicitly - by converting a DHTML object to a string. And here, as I already said, Mozilla behaves ugly: it never calls toString() on the applet, even when the applet is fully loaded. And it is not documented anywhere that the browser is required to use the toString Java class. A solution that relies on checking the string representation of a DHTML Applet object obviously falls into the first category: if a certain browser does not want to call the toString method, then on that browser the applet will ALWAYS be considered unloaded, and the user will not be able to work at all.
How do you make sure in JavaScript that the browser is good enough to understand the try...catch construct? I'm inclined to go this route for now.
Daniel Alievsky[dossier]
No, well, it’s clear that in MSIE the call toString() is an error, but the browser is easy to determine in javascript. If the browser is mozilla, call toString(), if not, just applet.
As for calling the toString method in the browser, as far as I understand, any object in javascript must have a toString method and if the browser does not call this method on the applet, then there are doubts that it is even possible to call applet methods in this browser - regardless of behavior in this case mozilla.
In short, we must first find such a browser and it is desirable that it be widespread enough, because otherwise I myself can quickly write a browser that would sabotage all attempts to determine how busy the applet is.
Well, yes. I just didn't think of it. Indeed, in my function I just need to refer not to the getAppletInfo method, but to the toString method. In MSIE, however, as before, there will be an error, but it is successfully caught through window.onerror. But in Opera - and in all browsers that allow you to call toString on an underloaded applet - there will be no errors at all, just toString will return either a string with a code word if the applet is loaded, or something default. At the same time, it seems that the browser should not be so strange that in a normally loaded applet the JavaScript call toString would not call the applet method of the same name.
It seems like a good solution has been found. Thanks for the help. I'll test it under all sorts of crooked browsers like Netscape 3 and propose it for the FAQ.
Alexander Samoilov[dossier] “As for calling the toString method in the browser, as far as I understand, any object in javascript must have a toString method and if the browser does not call this method in the applet, then there are doubts that it is generally possible to call in this browser applet methods..." - I didn’t quite understand you here, because the most popular MSIE believes that the Applet object does not have any toString if the applet is not loaded (for example, if the wrong class path is specified). I haven’t seen any clear instructions in the documentation that EVERY JavaScript object must have such a method. If there are any, point your finger, if not difficult.
quote from help for 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.From it, of course, it is impossible to unambiguously conclude that the same is true for all other javascript interpreters.
as for MSIE, it doesn't consider that the applet does not have a toString method, it considers that an unspecified error occurred while executing that method.
for example, if you try to call a obviously non-existent method on an applet, the error will be different.
Crap! You will laugh, but MSIE + Java 2 does not want to call toString() AT ALL on a NORMALLY loaded applet. Steadily produces Unspecified error. And when converted to a string by default, my overridden toString is simply ignored.
Maybe, of course, there is something wrong with my applet - in theory, I should do a clean test. But in any case - if at least on my applet this is the case, then the technology is incorrect.
Whatever. Yesterday I forgot to check this situation (I checked it under Java 1.1.4). Today I spent half an hour on a mysterious page glitch. Worse, as a “side effect,” MSIE began to freeze when opening a page (apparently due to my various helper scripts). Terrible.
Returned to the old technique with the getAppletInfo() call.
So, gentlemen, I am waiting for further proposals. In particular, how to catch Opera (in order to fight it separately).
Vladimir Palant[dossier] Thank you. Can I have the original source, if it doesn’t bother me? (I guess it's somewhere on the opera website.)
I would like not so much to discover Opera as to check JavaScript version that it supports try...catch - compatible with Opera way. The Microsoft version of such a check - conditional compilation - naturally does not work under Opera.
At worst, checking Opera is enough: in this case, you can (hopefully :-)) safely call toString on the applet.
Daniel Alievsky[dossier]
why not use the javascript version to catch try catch support
var try_catch = false
try_catch=true
if (try_catch) ()
I didn’t check it in opera though
Daniel Alievsky[dossier]
No, on opera.com they recommend checking using User-Agent (http://www.opera.com/support/search/supsearch.dml?index=570) - IMHO this is a perversion. It is more reliable to check using window.opera - no other browser will support this property.
Opera has supported try/catch since at least version 4.0, so you can assume it always supports it.
There is another idea - I haven't tested it yet. Accessing the properties of a DHTML object (property), as far as I know, never throws exceptions. If there is no such property, null is simply returned. It would be nice to provide the applet with a certain property (for example, boolean iAmLoaded=true) and check whether it is set. As far as I understand, in the case of Java 2 this is not so simple - it is not enough to create a public field, you need to declare a couple of get/set methods, as is required in JavaBeans (I have not yet studied the relevant documentation).
How reliable and cross-browser technology do you think this is?
I don’t understand what JavaBeans has to do with it; in my opinion, properties are accessed without any get/set. But in any case, you can check for the presence of a method, which is also a property for DHTML: if (typeof(applet.notifyAll) != "undefined") . But you'll have to check the cross-browser compatibility yourself...
Vladimir Palant[dossier]
There is a hint on JavaBeans Introspection here: http://java.sun.com/j2se/1.4.2......loper_guide/compatibility.html
As I understand it, the problem was temporary: on my computer, in all browsers and JRE, access to the public field works wonderfully. Moreover, it is absolutely not difficult to add a “real” public field of type boolean to the applet, then you will not need to resort to more exotic techniques like typeof(applet.notifyAll). (By the way, the mentioned typeof does not work for me in MSIE with neither 1.1.4 nor Java 2.)
The problem is that I used to use just such a technique - checking the existence of a public field - and one day I encountered a problem, and obviously of that very unpleasant first type: the field was not detected, the applet was detected as unloaded and completely refused to work. This happened on 2 “foreign” computers with a completely normal configuration (MSIE + Java 2, something like JRE 1.4.2_01), although everything worked on my computer. Naturally, I stopped using field checking - out of harm's way.
But maybe I just didn’t do everything correctly enough? For example, didn’t you declare get/set methods “in the JavaBean way”? If I don't see a clear description of this problem in the documentation, explaining why accessing a regular public field doesn't work on some browsers, and indicating how to do it correctly, I certainly won't risk using field validation - the cost of error is too high.
Error message interception, as it turns out, works even under Netscape 3. But - a little wrong: this ancient browser calls the message display procedure asynchronously with the general flow of JavaScript code, which leads to subtle errors. I haven't adjusted it yet. Naturally, no one needs compatibility with Netscape 3, but it is alarming that the technique (calling the applet method, or toString for Opera, with error interception) requires debugging “anew” for almost every class of browsers: (Apparently, after all, The technique is crooked. And which technique is “straight” is not yet clear.
With Netscape 3.0 the song turned out to be something completely different. This browser was generally not very friendly with requests like document.xxxx, where xxxx is the name of the applet. Even for a really loaded applet, it used to produce a whole bunch of errors when treated in this way:
Can"t reflect applet "(null)": not loaded yet
(The funny thing is that this also happens with checks like "if (document.getElementById != null)...".) The fight against this is very simple. It is enough to frame each call to any document.xxxx with code like:
var onerrorSaveLocal = window.onerror;
window.onerror = null; // - avoiding an incorrect exception in Netscape Navigator 3
var v = document.xxxx;
window.onerror = onerrorSaveLocal;
At the same time, as in Netscape 4, and in the built-in “browser” from JavaBuilder, when the applet is underloaded, document.Appletname simply returns null.
In general, I spent some time and debugged my procedure under all browsers that I could get my hands on - including previous versions MSIE. Here's what happened:
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 applet 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 occurs 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; )
As usual, MSIE caused maximum problems. Relevant: MSIE 5.0 appears to refuse to block error messages via window.onerror. I had to write a branch with conditional compilation and try..catch specifically for the “capricious” MSIE. At first glance, try..catch is the most reliable solution, so it is quite logical to use it in the most popular browser family. At the same time, in MSIE 4 (where there is no try..catch), as well as in Mozilla, error blocking through window.onerror continues to work. Opera uses a toString call and checks the "codeword" inside the result. It also turned out along the way that in MSIE 4 it is better not to try to access the applet from onbeforeunload - there may be errors.
I even got to MSIE 3.0 :-) There, it seems, my procedure did not work, although perhaps the point is that my classes are compiled in a way that is incompatible with Java 1.0.2, and I have no desire to maintain such compatibility.
Now I have a huge request to everyone present. Please test this procedure with some applet on all your browsers. For example, does it work on Unix Mozilla/Opera, or on Macintosh? Is it available in all versions of Windows+MSIE? What about more earlier versions Opera?
I tested in the following browsers:
Windows XP: MSIE 6.0 with Java 1.4.2 and Java 1.1.4, Mozilla 1.4, Opera 7.23, Netscape 4.5, Netscape Navigator 3.0;
Windows NT 4.0: MSIE 5.0 with Java 1.4 and Java 1.1.4, Netscape 4.5, Netscape Navigator 3.0;
Windows-95: MSIE 3.0 (Java 1.0.2), Netscape 4.5.
The easiest way to test is to indicate on the page a deliberately incorrect path to the applet (and, for comparison, the correct one) - in my opinion, this is quite similar to the situation when the applet did not load. If everything is fine, then, in theory, the procedure deserves to be included in the FAQ.
On this page, the "Get JVM information" button (using the function described above) should fire as soon as the applet is loaded, or "swear" until it is loaded.
(By the way, this technique does not work in MSIE 3.0 - in my version 3.02 JavaScript refuses to do anything at all if the applet is not loaded. And God bless him.)
In the article, I will tell you how to fix the Java applet is not loaded error. There have been a large number of web technologies available for over a decade. For example, Flash was used for multimedia and simple games, and ActiveX and Java were used for operations with high security requirements. But if ActiveX developed by Microsoft has long since sunk into oblivion, Java EE continues to be relevant to this day. And the point is not that there are no worthy analogues that are simpler for the end user (they just appeared several years ago), the problem is that some organizations have invested tens and hundreds of thousands of dollars in developing applications based on these technologies, and they just can’t give them up. That is why, when users try to log into a certain service, they may see a message: The Java applet is not loaded; we will look at what to do if you encounter it below.
Some VTB24 clients experience an error when trying to log into VTB24 online. It is precisely due to the fact that the Java applet is either not installed on the system, or it is disabled.
To fix this error with loading Java and log into your account control panel without any problems, you will need to follow a number of simple steps.
What to do if the Java applet is not loaded
First of all, you will need to install the software itself. If it's downloaded but not enabled, download it anyway - have the latest version installed. For this:
It should be noted that in Google Chrome(starting from version 42) the Java applet is not officially supported, since the corporation considers the corresponding technology obsolete. Therefore, to use Java, launch another web browser, for example, FireFox.
To avoid problems with Java, follow these steps:
After completing these steps, go to the site you are interested in - all its functionality (of course, if it does not use other third-party technologies) will work, and errors with loading the Java applet will not occur.
Is it possible to do without Java?If you do not need to use web applications (as is the case with the VTB24 banking client) created based on Java EE, then the corresponding applet is of no use to you. Gradually, even large companies are switching to technologies that are now more relevant for the web, making interaction with the functions of their services much easier for the end user.
In contact with
Many, many years ago, while working as an administrator at one of the city-forming enterprises in the Russian outback, I first encountered the concept of “ electronic digital signature"(hereinafter referred to as EDS).
At that time, the idea was ingrained in the minds of management that an electronic signature was an ordinary signature, scanned and added to all documents that must be “signed.”
Let's figure out what digital signature is and how it works.
To work with digital signature, we first of all need digital certificate and a private key.
First, we need to install an electronic signature under the document.
Installation of digital signature happens in two steps:
1. Take the document that we want to sign and calculate the hash of this document. (To put it simply, a hash is a one-way mathematical function of converting a document of arbitrary length into a document of a fixed length).
2. Then, we encrypt this resulting hash with our private key. 
Now we send the document, with the digital signature and our certificate attached to it, to the recipients. 
Having received the signed document, we need to check the signature - whether it is valid or not.
EDS verification is somewhat more complicated:
1. Take a document whose signature needs to be verified, and calculate the hash of this document.
2. We take the digital certificate of the user who signed the document and the digital signature attached to the document (which is a hash of the original document encrypted on the signer’s private key) and decrypt it using the public key.
Thus, we have two hashes - the one that we calculated ourselves and the one that we received along with the document and decrypted with the signer's public key.
3. Now let's compare these hashes. If the hashes match, then the signature is valid; if the hashes differ, then the signature is invalid. 
In conclusion, let’s determine what using a digital signature gives us:
1. Immutability during transmission or storage - if the document has been changed, then the hash that we calculate and which was attached to the document will be different, therefore, the signature will be invalid, from which we can conclude that the document has been changed;
2.
In order to make it impossible to forge an digital signature, the private key must be in a single copy and only the owner must have access to it. This can be implemented using smart cards, but that's a completely different story.
After rapid development information VTB, like many other banks, began to introduce a function called “remote banking”. For this purpose, VTB specialists created a special applet - a program through which clients gain access to their accounts. Most often, as in this case, language is used for these purposes Java programming(pronounced "java" or "yawa"). To start using the program from VTB, you need to download the program, install and configure it.
What is a Java Applet for?This applet works based on three pillars. Their names are: Reliability, Performance and Security. So it is not surprising that applets on this platform are used not only by financial organizations like VTB, but also by accounting departments, scientific enterprises, as well as manufacturers of technical products for household and commercial needs. The platform's capabilities are multifaceted:
- an easy way to create and configure a network application;
- accessibility to work with databases;
- detailed study of unique scenarios for the development of events;
- ability to select filter parameters on input and output;
- access to Internet services;
- automatic memory management;
- full-fledged work with forums, online stores, questionnaires, games and applications on the Internet;
- several programs are executed simultaneously in any of the specified languages;
- support for multi-threaded applications;
- possible messages and errors if it is not loaded;
- various classes for making HTTP requests and processing responses.
The described advantages make the Java platform ideal for the VTB applet.
Possible mistakesBelow are the most common errors that VTB clients encounter after installing the applet, and how to resolve them.
Applet does not launch after updating to Java 7 Update 65This problem most often affects owners of Windows 7, 8 and 10, with Java versions 7.0 or 8.0. The essence of the problem boils down to the fact that the VTB applet has stopped running. The reason lies in the absence of the deployment.javaws.jre.0.args= line in the document named deployment.properties. The developers have fixed problems in Java 7 Update 67 (7u67), so for most, the solution to the problem is to install latest version BY. You can download the program from the link: https://www.java.com/ru/download/. Home page looks like that: 
In cases where updating is not possible, there are other options. End users of version 7u65 should change the Java settings slightly Control Panel. You can do this as follows:
By following this guide, anyone can set up their VTB applet quite quickly.
You can temporarily solve the problem by amending the code:
This way you will make the VTB applet work and the problem with the update will be solved.
VTB applet is not loadedAn important backstory: of the many technologies that companies used, some were hopelessly outdated and no longer able to perform their functions as intended. However, the owners of large enterprises really regret spending tens/hundreds of thousands of dollars on the development of corporate applications based on the mentioned technologies. In this regard, some clients, when logging into the service, may see an error with the above name.
This also applies to some VTB clients: when trying to log into the system remote control The abacus displays the described applet error. The reason may be that the applet is missing or is not working. However, this is easy to deal with, just follow the simple instructions below.
The easiest way to start is to install the VTB applet from the official Java website. It’s worth doing this even when you already have the software, but it’s not turned on: it will be better if the most current version programs. So, follow the directions:
Important information: starting from version 42, Google Chrome does not officially support Java-based applets, including the VTB applet.
However, it is available in any other browser, for example, Mozilla Firefox. You can enable the applet there as follows:
After these simple manipulations, you can freely access the VTB service: the applet should work without interruptions.
Installing the VTB appletTo install and configure the VTB applet, download it from the link http://www.java.com⁄ru⁄. The applet is suitable for the functionality of such browsers as FireFox, Opera, Internet Explorer(the version of which must be constantly updated).
The applet for working with VTB is installed in two stages:
- installation and configuration of the SE Runtime Environment platform;
- installation of the applet itself.
If you plan to use a personal computer for access, you do not need the first step. The installation procedure consists of five points:
Then the script needs to be configured:
“Start” =› control panel =› uncheck TLS protocols 1.1, TLS 1.2 and “Use SSL 2.0 compatible ClientHello format”. Now you have free access to the VTB applet.
Browser settingsWarning window with the message “Attention. Java applet not loaded" may occur due to browsers. To configure them to interact with the VTB applet, follow the instructions in the table below.
| Firefox | 1. Click on the icon. |
| 2. In the drop-down menu, select the “Allow and remember” status. | |
| 3. Click OK. | |
| 4. Go to your browser settings. | |
| 5. Select “Add-ons”, sub-item “Plugins”. | |
| 6. Set the status “Enable on request” for all Java sub-items. | |
| Opera | 1. Open your browser settings. |
| 2. In the “Plugins (recommended)” item, select “Run all plugin contents”. | |
| Safari | 1. On the registration page in the VTB system, select the menu “Safari” => “Settings” => “Security” => “Customize website”. |
| 2. Select “Java” in the left list of the dialog. In the right list for the VTB website, set the mode to “On”. | |
| 3. Press and hold ALT while moving the mouse cursor to ON. Then click the mouse button. A drop-down menu will appear, from which you select “Run in safe mode». | |
| 4. Click "Done" and restart your browser. | |
| Internet Explorer | 1. In the browser settings, select “Tools” => “Internet Options” => “Advanced”. Uncheck SSL 2.0 and disable the use of TLS 1.1 and 1.2 protocols. |
| 2. In your browser settings, select “Customize add-ons.” | |
| 3. In the window that appears, select “Run without permission.” | |
| 4. In the list of add-ons, find “Java Plug-in”. The state of this add-on should be Enabled. |
So, the VTB applet is a very useful thing, so it is important to know how to correctly install the software for it. For those who like visual demonstrations, watch the video.