Da biste instalirali i naknadno konfigurirali sustav CryptoPro Bank-Client Online, morat ćete preuzeti java applet za VTB 24. Možete ga besplatno preuzeti na stranici http://www.java.com/ru/. Ova komponenta će vam biti potrebna ako koristite preglednike kao što su Mozilla Firefox,Opera, Internet Explorer. Ali to nisu jedini preglednici koje ovaj sustav podržava.
Instalacija java appleta odvija se u dvije faze:
Ako je java na vašem osobno računalo, prvi korak treba preskočiti. Usput, računalo neće od vas tražiti da instalirate ovu komponentu. Instalacija se odvija u pet koraka:
Konfiguracija se provodi putem "Start" na "Upravljačkoj ploči". Zatim otvorite upravljačka ploča. Sve što trebate učiniti je onemogućiti protokole: TLS 1.1 i TLS 1.2. To je lako učiniti: poništite ih. Isti način onemogućite "Koristi ClientHello format kompatibilan sa SSL 2.0". Sve je spremno.
Prije mnogo, mnogo godina, radio sam kao administrator u jednom od gradskih poduzeća Ruska divljina, morao sam se prvi put susresti s pojmom " elektronički digitalni potpis“ (u daljnjem tekstu EDS).
U to je vrijeme u glavama menadžmenta bila ukorijenjena ideja da je elektronički potpis običan potpis, skeniran i pridodan svim dokumentima koji se moraju “potpisati”.
Razmotrimo što je digitalni potpis i kako funkcionira.
Za rad s digitalnim potpisom prije svega nam je potreban digitalni certifikat i privatni ključ.
Prvo moramo instalirati elektronički potpis ispod dokumenta.
Instalacija digitalnog potpisa odvija se u dva koraka:
1. Uzmite dokument koji želimo potpisati i izračunajte hash tog dokumenta. (Pojednostavljeno rečeno, hash je jednosmjeran matematička funkcija pretvaranje dokumenta proizvoljne duljine u dokument fiksne duljine).
2. Zatim šifriramo ovaj rezultirajući hash s našim privatnim ključem. 
Sada primateljima šaljemo dokument s digitalnim potpisom i priloženim našim certifikatom. 
Nakon što smo primili potpisani dokument, potrebno je provjeriti potpis - je li valjan ili ne.
EDS provjera je nešto kompliciranija:
1. Uzmite dokument čiji potpis treba ovjeriti i izračunajte hash tog dokumenta.
2. Uzmite digitalni certifikat korisnika koji je potpisao dokument i priložio ga EDS dokument(što je hash izvornog dokumenta šifriranog na potpisnikovom privatnom ključu) i dekriptiranog pomoću javnog ključa.
Dakle, imamo dva hasha - onaj koji smo sami izračunali i onaj koji smo dobili uz dokument i dešifrirali javni ključ potpisnik
3. Sada usporedimo ove hashove. Ako se hashovi podudaraju, tada je potpis važeći; ako se hashovi razlikuju, onda je potpis nevažeći. 
Zaključno, odredimo što koristiti digitalni potpis:
1. Nepromjenjivost tijekom prijenosa ili pohrane - ako je dokument promijenjen, tada će hash koji smo izračunali i koji je priložen dokumentu biti drugačiji, dakle potpis će biti nevažeći, iz čega možemo zaključiti da je dokument promijenjeno;
2.
Kako bi se onemogućilo krivotvorenje digitalnog potpisa, privatni ključ mora biti u jednom primjerku i samo vlasnik mora imati pristup istom. To se može implementirati pomoću pametnih kartica, ali to je sasvim druga priča.
Problem je ovo.
Stranica sadrži applet, kao i sučelje za upravljanje njime, napisano u HTML + JavaScript. Iz JavaScripta trebate utvrditi da je applet učitan i spreman za rad. Rješenje mora biti IZUZETNO pouzdano - cross-browser, osjetljivo na spori Internet itd.
komentiram. Sve dok se aplet ne učita, pozivi iz JavaScripta njegovim javnim metodama i/ili poljima puni su izgleda vrlo ružne poruke s nečim poput ovoga: " Ova metoda nedostaje." A apletu ponekad treba puno više vremena da se učita nego samoj stranici. Štoviše, ponekad ima smisla učiniti neke stvari automatski (iz JavaScripta) čim se aplet učita - recimo, dajte mu neku naredbu.
Problem ovdje nije toliko u tome što ne postoji način provjere je li se applet već učitao, već u tome što takvih metoda ima napretek. Na primjer: učitavanje apleta, učitavanje stranice, pozivanje metode ili polja apleta, "aktivno" obavještavanje stranice da je aplet učitan posebnim Java kodom iz samog apleta, itd. I povjerenje da će ove metode djelovati:
na svakom zamislivom pregledniku,
pred svima Sigurnosne postavke u preglednicima,
u kombinaciji sa svim zamislivim platformama,
sa svim JRE-ovima,
Ja nemam. A steći takvo povjerenje gotovo je nemoguće: previše je kombinacija.
Još gore od toga, čini se da je ovdje vrlo lako "pretjerati". Na primjer, jučer sam se dugo "mučio" s greškom - na tuđem računalu (XP+ MSIE + Java2), JavaScript je pogrešno pretpostavio da aplet nije učitan, iako je na mom računalu sve bilo u redu. Pretpostavljam da sam tada upotrijebio pristup određenoj javnoj varijabli apleta (ne metodi!) za provjeru dostupnosti. Svi preglednici na mom računalu (također XP) vraćaju null kada pristupaju takvoj varijabli nedovoljno opterećenog appleta, a čim se applet učita vraćaju njegovu vrijednost. (Nasuprot tome, pozivanje metode na nedovoljno opterećenom appletu proizvodi pogrešku.) Bojim se da je na tuđem računalu preglednik odbio čitati javnu varijablu. Pristup varijablama općenito je neočita stvar koja radi različito pod različitim preglednicima i JRE-ovima. Samo pozivanje metoda je pouzdano, ali samo kada je applet učitan.
Do sada sam napisao sljedeći par funkcije:
Funkcija showMyErrorMessage(msg,url,line) ( if (window.errorMessage != null) alert(window.errorMessage); window.onerror = window.onerrorSave; return true; ) funkcija getApp(name,notShowMessage) ( window.errorMessage = null;var a = " Pogreška dok pristup apletu informacije za the \"" + name + "\" Java applet."; var b = "Možda, ovaj applet nije pravilno učitan. Pokušajte ponovno učitati ovu stranicu."; if (notShowMessage==null || !notShowMessage) ( prozor .errorMessage = a + b; window.onerror = showMyErrorMessage; var appInfo == null: window.onerror = onerrorSave ; if (app == null || appInfo == null) ( if (window.errorMessage != null) ( if (app == null) alert("Ne mogu pristupiti \"" + name + " \" Java applet." + b); else alert("Ne mogu pristupiti informacijama o appletu za \"" + name + "\" return null ) return app;
Koristimo prilično staru (u teoriji, cross-browser) tehniku za suzbijanje poruka o pogreškama putem window.onerror. Sve radi pod Mozillom 1.4, MSIE 6.0 pa čak i pod drevnim Netscapeom 4.5, ali, nažalost, ne pod (mnogo popularnijom) Operom 7.23: potonja prikazuje poruku o JavaScript greška. Pozivanje neke metode apleta je neophodno - jer gotovo svi preglednici (osim Netscape-a) uspješno vraćaju objekt koji nije null document.AppletName čim se TAG pročita na stranici
Među ostalim metodama provjere, sve vrste onload-a izazivaju kod mene nepovjerenje - jedno vrijeme (na starim preglednicima) često sam morao ispravljati pogreške u situacijama kada je onload bez vidljivi razlozi odbio se aktivirati, na primjer kada pritisnete Refresh za stranicu ili nešto slično. Čini se da je najpouzdanije "aktivno" informiranje stranice - kada Java kod appleta pristupa JavaScriptu. Ali ovdje se čini da je jedino rješenje za više preglednika showDocument in poseban prozor(ili okvir), što rješenje čini izuzetno glomaznim.
Možda netko može predložiti pouzdano, po mogućnosti objavljeno i naširoko poznata metoda provjera učitavanja apleta?
Za Operu, uzgred, konstrukcija try...catch radi dobro. Ali samo će ova ista konstrukcija, ako se ne varam, dovesti do sintaktičke pogreške u ranom MSIE-u, koji još uvijek premašuje Operu po popularnosti. Kako mogu pouzdano biti siguran da se try...catch može koristiti? MSIE uvjetna kompilacija -
/*@cc_on @*/ /*@if (@_jscript_version >= 5) (ovdje koristite try..catch i druge dobre stvari) @*/ /*@end @*/
Kao i obično, zanemaruje se u Operi :(
Pretpostavljam da mislite na paket netscape.javascript.*?
Ovo rješenje nije prenosivo - ako se ne varam, u MSIE-u s ugrađenim JRE 1.1.4 ova tehnika je počela raditi tek negdje oko verzije 5.5 ili čak i više. Nikada nisam koristio ovaj paket - zbog netolerancije; možda griješim? Napisao sam o ovome gore: "ovdje se čini da je jedino rješenje za više preglednika showDocument u zasebnom prozoru (ili okviru), što rješenje čini iznimno glomaznim."
Obično kompajliram aplete u JDK 1.1.6 (najstarija verzija dostupna u Sun arhivama); Ovog paketa uopće nema.
A ako ogradite vrt, uzimajući u obzir da paket netscape.javascript.* možda ne postoji, onda neće ispasti ništa bolje nego, na primjer, zasebno provjeriti operu i koristiti try...catch for it.
Bilo je to davno :) Opcije:
public void init() (
//....
getAppletContext().showDocument("js_page.htm", "još jedan_okvir");
}
Primjer iz 1998. - http://www.copris.com/optocontrol/home.htm - radi u IE5.5 i Mozilli 1.6 (rađeno u danima NN3 i IE3) :)
funkcija checkApplet() (
if (dokument && dokument["appletName"] && dokument["appletName"].isActive())
//Učini nešto
drugo
setTimeout(checkApplet, 100);
}
isActive() je metoda u klasi java.applet.Applet.
Alexey Ryumin zvani Patuljak [dossier]
Hvala puno. Ali...
Nažalost, moja se stranica po prirodi ne temelji na okvirima, a uvođenje okvira samo radi apleta vrlo je nezgodno. A opcija s IFRAME-om nije cross-browser - neće biti ništa bolja od mog rješenja s window.onerror.
Zapravo, moji appleti s 3D strukturama već su prisutni na nekoliko naših stranica, au budućnosti će biti još mnogo takvih stranica (sve vrste galerija primjera struktura itd.). Zapravo, na našoj web stranici programčići će zauzimati približno isti prostor kao i slike ( ): ilustracija za tekst, koja se može "vrtati" i mišem. I pored svakog takvog apleta vjerojatno će biti neki jednostavni JavaScript kontrolni gumbi: dobro, barem za rotiranje rotirane trodimenzionalne slike u njezin izvorni položaj.
Otud potreba univerzalna funkcija kao što je moj getApp, koji se može smjestiti u uključenu js datoteku i za koji nema potrebe pretvarati stranice u okvire.
Napišimo jednostavan test.
... upozorenje(document.XXXX+""+document.XXXX.isActive());
Zatim učitavamo ovu stranicu putem bilo kojeg interneta koji nije instant, nakon što smo prvo očistili MSIE predmemoriju. Kao što možete očekivati, dok se applet stvarno ne učita (sivi kvadrat), poziv isActive() generira gornju poruku o pogrešci. U isto vrijeme, pozivanje document.XXXX radi normalno, što možete potvrditi promjenom koda u
upozorenje(dokument.XXXX);
Budući da je objekt stranice XXXX već prikazan, preglednik dopušta slobodan pristup ovom objektu.
Istina, ovdje se pojavljuje jedna zanimljiva nijansa. Pretvaranje objekta apleta u niz daje različite rezultate ovisno o tome je li se aplet učitao ili još nije. Naime, ako je applet učitan, tada pretvaranje DHTML objekta u niz daje rezultat pozivanja “toString()” na appletu. U teoriji, napisao bih nešto u toString metodi ključna riječ i provjerite da li je ova riječ prisutna u retku document.appletname+"".
Bilo bi jednostavno divno, vrlo jednostavno i lijepo, pa čak i funkcionira u Operi. Ali – jao – ovaj put nas je Mozilla iznevjerila. Pokazuje infekciju, glupo, bez obzira na činjenicu učitavanja. Pa neće ići...
Za sada - recite mi kako da pouzdano "otkrijem" s čime imamo posla moderna opera- točnije, što do try...catch work? Čini se da Opera ima naviku pretvarati se da su drugi preglednici. Ako saznate da try..catch radi, možete nazvati verziju koda s ovim operatorima preko eval - također radi pod Operom.
Više o istoj temi. Predlažem dijeljenje moguća rješenja problema u dvije grupe.
Ako je moguće, ograničite se na rješenja druge vrste.
Nešto vam nije jasno, dragi moji.
Ne možete EKSPLICITNO pozvati toString()! Objekt DHTML apleta NEMA vlastitu metodu toString, pojavljuje se samo kada se učita Java klasa. Sukladno tome, pokušaj izvođenja
upozorenje(document.PackingSpheresForDesign.toString());
kada se applet ne učita, rezultira pogreškom JavaScripta, u mom MSIE-u to je "Neodređena pogreška".
Naravno, uvijek možete implicitno pozvati toString - pretvaranjem DHTML objekta u niz. I ovdje se, kao što sam već rekao, Mozilla ružno ponaša: nikad ne poziva toString() na apletu, čak ni kada je aplet potpuno učitan. I nigdje nije dokumentirano da preglednik mora koristiti Java klasu toString. Rješenje koje se oslanja na provjeru string reprezentacije DHTML Applet objekta očito spada u prvu kategoriju: ako određeni preglednik ne želi pozvati metodu toString, tada će se u tom pregledniku aplet UVIJEK smatrati neučitanim, a korisnik će uopće ne moći raditi.
Kako se u JavaScriptu uvjeriti da je preglednik dovoljno dobar da razumije try...catch konstrukciju? Za sada sam sklon ići ovim putem.
Daniel Alievsky[dosje]
Ne, dobro, jasno je da je u MSIE-u poziv toString() pogreška, ali preglednik je lako odrediti u javascriptu. Ako preglednik mozilla, pozovite toString(), ako ne, samo aplet.
Što se tiče pozivanja metode toString u pregledniku, koliko ja razumijem, svaki objekt u javascriptu mora imati metodu toString i ako preglednik ne poziva ovu metodu na apletu, onda postoje sumnje da je uopće moguće pozvati aplet metode u ovom pregledniku - bez obzira na ponašanje u ovom slučaju mozilla.
Ukratko, prvo moramo pronaći takav preglednik i poželjno je da bude dovoljno raširen, jer inače i sam mogu brzo napisati preglednik koji bi sabotirao sve pokušaje utvrđivanja zauzetosti appleta.
Pa da. Samo mi to nije palo na pamet. Doista, u svojoj funkciji samo se moram pozvati ne na metodu getAppletInfo, već na metodu toString. U MSIE-u će, međutim, kao i prije, biti pogreške, ali se uspješno hvata kroz window.onerror. Ali u Operi - i u svim preglednicima koji vam dopuštaju pozivanje toString na nedovoljno opterećenom apletu - neće biti nikakvih pogrešaka, samo će toString vratiti ili niz s kodnom riječi ako je aplet učitan, ili nešto zadano. U isto vrijeme, čini se da preglednik ne bi trebao biti toliko čudan da u normalno učitanom appletu JavaScript poziv toString ne bi pozvao metodu appleta istog imena.
Čini se da je pronađeno dobro rješenje. Hvala na pomoći. Testirat ću ga pod svim vrstama pokvarenih preglednika kao što je Netscape 3 i predložiti ga za FAQ.
Alexander Samoilov[dossier] “Što se tiče pozivanja metode toString u pregledniku, koliko ja razumijem, bilo koji objekt u javascriptu mora imati metodu toString i ako preglednik ne poziva ovu metodu u apletu, onda postoji sumnja da općenito ga je moguće nazvati u ovom pregledniku applet metode..." - Ovdje te nisam baš razumio, jer najpopularniji MSIE vjeruje da Applet objekt nema nikakav toString ako aplet nije učitan (na primjer, ako je naveden pogrešan put klase). U dokumentaciji nisam vidio nikakve jasne naznake da SVAKI JavaScript objekt mora imati ovu metodu. Ako ih ima, uperi prstom, ako nije teško.
citat iz pomoći za JScript
The Objekt objekt sadržan je u svim drugim JScript objektima; sve njegove metode i svojstva dostupni su u svim drugim objektima. Metode se mogu redefinirati u objektima koje definira korisnik, a poziva ih JScript u odgovarajuće vrijeme. Metoda toString je primjer često redefinirane Object metode.Iz njega je, naravno, nemoguće jednoznačno zaključiti da isto vrijedi i za sve ostale javascript interpretere.
što se tiče MSIE, ne smatra se da applet nema toString metodu, smatra se da je došlo do neodređene pogreške tijekom izvršavanja te metode.
na primjer, ako pokušate pozvati očito nepostojeću metodu na apletu, pogreška će biti drugačija.
Sranje! Smijat ćete se, ali MSIE + Java 2 UOPĆE ne želi pozvati toString() na NORMALNO učitanom appletu. Stalno proizvodi neodređenu pogrešku. A kada se prema zadanim postavkama pretvori u niz, moj nadjačani toString jednostavno se zanemaruje.
Možda, naravno, nešto nije u redu s mojim appletom - u teoriji bih trebao napraviti čisti test. Ali u svakom slučaju - ako je barem na mom appletu to slučaj, onda tehnologija nije ispravna.
Što god. Jučer sam zaboravio provjeriti ovu situaciju (provjerio sam pod Javom 1.1.4). Danas sam proveo pola sata na misterioznom problemu stranice. Što je još gore, kao "nuspojava", MSIE se počeo smrzavati pri otvaranju stranice (navodno zbog mojih raznih pomoćnih skripti). Strašno.
Povratak na staru tehniku s pozivom getAppletInfo().
Dakle, gospodo, čekam daljnje prijedloge. Konkretno, kako uhvatiti Operu (kako bi se protiv nje zasebno borili).
Vladimir Palant [dossier] Hvala. Mogu li dobiti izvorni izvor, ako mi ne smeta? (Pretpostavljam da je negdje na web stranici opere.)
Ne želim toliko otkriti Operu koliko provjeriti JavaScript verzija koje podržava try...catch - kompatibilan sa Opera način. Microsoftova verzija takve provjere - uvjetna kompilacija - naravno ne radi pod Operom.
U najgorem slučaju, provjera Opere je dovoljna: u ovom slučaju, možete (nadajmo se :-)) sigurno pozvati toString na apletu.
Daniel Alievsky[dosje]
zašto ne upotrijebiti javascript verziju za catch pokušajte uhvatiti podršku
var try_catch = false
try_catch=true
if (try_catch) ()
Ipak nisam provjerio u operi
Daniel Alievsky[dosje]
Ne, na opera.com preporučuju provjeru pomoću User-Agenta (http://www.opera.com/support/search/supsearch.dml?index=570) - IMHO ovo je perverzija. Pouzdanije je provjeriti pomoću window.opere - nijedan drugi preglednik neće podržati ovo svojstvo.
Opera podržava try/catch barem od verzije 4.0, tako da možete pretpostaviti da to uvijek podržava.
Postoji još jedna ideja - nisam je još testirao. Pristup svojstvima DHTML objekta (property), koliko ja znam, nikada ne baca iznimke. Ako ne postoji takvo svojstvo, null se jednostavno vraća. Bilo bi lijepo dati apletu određeno svojstvo (na primjer, boolean iAmLoaded=true) i provjeriti je li postavljeno. Koliko sam shvatio, u slučaju Jave 2 to nije tako jednostavno - nije dovoljno stvoriti javno polje, potrebno je deklarirati nekoliko get/set metoda, kao što je potrebno u JavaBeansu (još nisam proučio relevantnu dokumentaciju).
Što mislite koliko je ovo pouzdana tehnologija za više preglednika?
Ne razumijem kakve veze ima JavaBeans s tim; po mom mišljenju, svojstvima se pristupa bez ikakvog dobivanja/postavljanja. Ali u svakom slučaju, možete provjeriti prisutnost metode, koja je također svojstvo za DHTML: if (typeof(applet.notifyAll) != "undefined") . Ali morat ćete sami provjeriti kompatibilnost s više preglednika...
Vladimir Palant[dosje]
Ovdje postoji savjet o JavaBeans Introspection: http://java.sun.com/j2se/1.4.2......loper_guide/compatibility.html
Koliko sam shvatio, problem je bio privremen: na mom računalu, u svim preglednicima i JRE-u, pristup javnom polju radi izvrsno. Štoviše, apletu apsolutno nije teško dodati "pravo" javno polje tipa boolean, tada nećete morati pribjegavati egzotičnijim tehnikama poput typeof(applet.notifyAll). (Usput, spomenuti typeof mi ne radi u MSIE-u ni s 1.1.4 ni s Javom 2.)
Problem je što sam prije koristio upravo takvu tehniku - provjeravao postojanje javnog polja - i jednog dana sam naišao na problem, i to očito vrlo neugodnog prvog tipa: polje nije detektirano, applet je detektiran kao neučitan i potpuno odbio raditi. To se dogodilo na 2 “strana” računala s potpuno normalnom konfiguracijom (MSIE + Java 2, nešto kao JRE 1.4.2_01), iako je na mom računalu sve radilo. Naravno, prestao sam koristiti terensku provjeru - bez opasnosti.
Ali možda jednostavno nisam sve napravio dovoljno ispravno? Na primjer, niste li deklarirali get/set metode "na JavaBean način"? Ako u dokumentaciji ne vidim jasan opis ovog problema, koji objašnjava zašto pristup redovnom javnom polju ne radi na nekim preglednicima i ukazuje kako to učiniti ispravno, sigurno neću riskirati korištenje provjere valjanosti polja - cijena pogreške je previsoka.
Presretanje poruka o pogrešci, kako se ispostavilo, radi čak i pod Netscapeom 3. Ali - malo pogrešno: ovaj drevni preglednik poziva proceduru prikaza poruke asinkrono s općim tokom JavaScript koda, što dovodi do suptilnih pogrešaka. Još ga nisam prilagodio. Naravno, nitko ne treba kompatibilnost s Netscapeom 3, ali alarmantno je da tehnika (pozivanje metode appleta, ili toString za Operu, s presretanjem pogrešaka) zahtijeva "novo" otklanjanje pogrešaka za gotovo svaku klasu preglednika: (Očigledno, nakon svega, tehnika je kriva, a koja je tehnika "ravna", još uvijek nije jasno.
S Netscapeom 3.0 pjesma je ispala nešto sasvim drugačije. Ovaj preglednik općenito nije bio prijateljski raspoložen prema zahtjevima kao što je document.xxxx, gdje je xxxx naziv apleta. Čak i za stvarno učitane applete, znao je proizvoditi čitavu hrpu pogrešaka kada se tretirao na ovaj način:
Ne može prikazati aplet "(null)": još nije učitan
(Smješno je da se to također događa s provjerama poput "if (document.getElementById != null)...".) Borba protiv ovoga je vrlo jednostavna. Dovoljno je uokviriti svaki poziv bilo kojem dokumentu.xxxx kodom poput:
var onerrorSaveLocal = window.onerror;
window.onerror = null; // - izbjegavanje netočne iznimke u Netscape Navigatoru 3
var v = dokument.xxxx;
window.onerror = onerrorSaveLocal;
U isto vrijeme, kao u Netscape 4, iu ugrađenom "pregledniku" iz JavaBuildera, kada je applet premalo učitan, document.Appletname jednostavno vraća null.
Općenito, proveo sam neko vrijeme i otklonio pogreške u svojoj proceduri pod svim preglednicima do kojih sam mogao doći - uključujući prethodne verzije MSIE. Evo što se dogodilo:
Funkcija showMyErrorMessage(msg,url,line) ( if (window.errorMessageA != null) alert(window.errorMessageA+"(Poruka o pogrešci sustava: "+msg+")"+window.errorMessageB); window.onerror = window.onerrorSave; return true; ) function getApp(name,notShowMessage) ( // Radi kompatibilnosti s ovom funkcijom, svi Java aplet moraju nadjačati metodu "toString()" // i vratiti niz koji sadrži podniz "Uspješno učitan Java aplet" kao rezultat . window.errorMessageA = window.errorMessageB = null; if (notShowMessage==null || !notShowMessage) ( window.errorMessageA = "Greška prilikom pristupa informacijama o apletu za \"" + "\" Java aplet."; .errorMessageB = "Možda se ovaj aplet ne učitava ispravno." + "Pričekajte dok se potpuno ne učita," + "pokušajte ponovno učitati ovu stranicu." var opera = window.opera != null; .onerrorSave == null) window.onerrorSave = window.onerror; var appInfo = null; window.onerror = null; // - izbjegavanje neispravne iznimke u Netscape Navigatoru 3 // ("Ne može odražavati aplet "(null)": još nije učitano") // ponekad se pojavljivao tijekom pristupanja ispravno učitanim apletima app = eval("document."+name ); window.onerror = onerrorSaveLocal; var systemErrorMessage = null /*@cc_on@*/ /*@if (@_jscript_version >= 5) try ( // neki MSIE (na primjer, MSIE 5.0) ne razumiju onerror-based hvatanje @else @*/ window.onerror = showMyErrorMessage; // hvatanje iznimaka pri pozivanju nepostojeće metode /*@end @*/ appInfo = app == null: // slučaj aplikacije preglednika Netscape toString(): / / MSIE + Java2 ne može pozvati applet"s toString app.getAppletInfo(); // MSIE i Mozilla (ali ne i Opera) će ovdje uhvatiti iznimku /*@if (@_jscript_version >= 5) ) catch( e) ( systemErrorMessage = e==null? e.description+""; window.onerrorSave = null; if (app == null || systemErrorMessage != null || appInfo == null || (opera && (appInfo+"").indexOf("Uspješno učitana Java aplikacija")==-1)) ( if (window.errorMessageA != null) ( if (app == null) alert("Ne mogu pronaći \"" + name + "\" Java applet." + window.errorMessageB); else if (systemErrorMessage != null) alert("Dogodila se iznimka prilikom pristupa informacijama apleta za \"" + name + "\" Java applet. (Sustav informacije o iznimci: " + systemErrorMessage + ")" + window.errorMessageB); else if (appInfo == null) alert("Ne mogu pristupiti informacijama appleta za \"" + name + "\" Java applet. " + window.errorMessageB); else alert("Ne mogu pozvati \"" + name + "\" Java applet." + window.errorMessageB); ) return null; ) return app; )
Kao i obično, MSIE je izazvao najviše problema. Relevantno: čini se da MSIE 5.0 odbija blokirati poruke o pogrešci putem window.onerror. Morao sam napisati granu s uvjetnom kompilacijom i pokušati..uhvatiti posebno za "hiroviti" MSIE. Na prvi pogled, try..catch je najpouzdanije rješenje, pa je sasvim logično koristiti ga u najpopularnijoj obitelji preglednika. U isto vrijeme, u MSIE 4 (gdje nema try..catch), kao iu Mozilli, blokiranje pogreške kroz window.onerror nastavlja raditi. Opera koristi poziv toString i provjerava "kodnu riječ" unutar rezultata. Usput se također pokazalo da je u MSIE 4 bolje ne pokušavati pristupiti appletu iz onbeforeunloada - može biti grešaka.
Stigao sam čak i do MSIE 3.0 :-) Tu, čini se, moj postupak nije funkcionirao, iako je možda stvar u tome što su moje klase kompajlirane na način koji nije kompatibilan s Javom 1.0.2, a ja nemam želju održavati takav kompatibilnost.
Sada imam veliku molbu za sve prisutne. Testirajte ovaj postupak s nekim programčićem na svim svojim preglednicima. Na primjer, radi li na Unix Mozilla/Opera ili na Macintosh? Je li dostupan u svim verzijama Windows+MSIE? Što s više ranije verzije Opera?
Testirao sam u sljedećim preglednicima:
Windows XP: MSIE 6.0 s Javom 1.4.2 i Javom 1.1.4, Mozilla 1.4, Opera 7.23, Netscape 4.5, Netscape Navigator 3.0;
Windows NT 4.0: MSIE 5.0 s Javom 1.4 i Javom 1.1.4, Netscape 4.5, Netscape Navigator 3.0;
Windows-95: MSIE 3.0 (Java 1.0.2), Netscape 4.5.
Najlakši način za testiranje je naznačiti na stranici namjerno pogrešan put do appleta (i, za usporedbu, ispravan) - po mom mišljenju, to je prilično slično situaciji kada se aplet nije učitao. Ako je sve u redu, onda, teoretski, postupak zaslužuje da bude uključen u FAQ.
Na ovoj stranici, gumb "Get JVM information" (koristeći gore opisanu funkciju) trebao bi se aktivirati čim se aplet učita ili "psovati" dok se ne učita.
(Usput, ova tehnika ne radi u MSIE 3.0 - u mojoj verziji 3.02 JavaScript odbija učiniti bilo što ako aplet nije učitan. I Bog ga blagoslovio.)
Ovaj odjeljak odnosi se na:- Platforme: Sve platforme
- Verzije Jave: 7.0, 8.0
Prilikom pokretanja appleta ili Java aplikacije Pojavljuje se dijaloški okvir sigurnosnog upozorenja:
Blokirati rad potencijalno nesigurnih komponenti?
Java okruženje je otkrio komponente aplikacije koje mogu ukazivati na sigurnosne rizike. Obratite se davatelju aplikacije kako biste bili sigurni da nema pokušaja neovlaštenog pristupa.
UZROK
Potpisane aplikacije i apleti Java Web Start koji sadrži potpisane i nepotpisane komponente može biti potencijalno nesiguran osim ako je dobavljač aplikacije namjerno upotrijebio miješani kod. Počevši od Java SE 6 ažuriranja 19, kada radite s programom koji sadrži potpisane i nepotpisane komponente, prikazuje se dijaloški okvir upozorenja.
RIJEŠENJE
Ako kliknete Da u sigurnosnom dijaloškom okviru, pokretanje potencijalno nesigurnih komponenti bit će blokirano, nakon čega se program može prekinuti. Ako kliknete Ne, aplikacija ili applet nastavit će raditi.
Upozorenje se prikazuje prema zadanim postavkama, ali postoje opcije za promjenu ove postavke.
Možete konfigurirati kako se rukuje programima s mješovitim kodom pomoću Java Control Panela.
Na Javinoj upravljačkoj ploči pronađite postavke zaštite miješanog koda Java Control Panel
DODATNE TEHNIČKE INFORMACIJE
Za programere Java aplikacija: vidi
