Gabim. Mjedisi Java ka zbuluar komponentë aplikacioni që mund të tregojnë praninë e rreziqeve të sigurisë

Shkarkoni dhe instaloni aplikacionin java

Për të instaluar dhe konfiguruar më pas CryptoPro të sistemit Bank-Klient Online, do t'ju duhet të shkarkoni një aplikacion java për VTB 24. Mund ta shkarkoni falas në faqen http://www.java.com/en/. Ky komponent do t'ju duhet nëse do të përdorni shfletues si p.sh Mozilla Firefox Opera, Internet Explorer. Por këta nuk janë të vetmit shfletues që mbështet ky sistem.

Instalimi i apletit Java zhvillohet në dy faza:

1. ky është instalimi i vetë platformës java SE Runtime Environment;
2. instalimi i aplikacionit java.

Nëse java është në tuaj Kompjuter personal, hapi i parë duhet të anashkalohet. Nga rruga, PC nuk do t'ju kërkojë të instaloni këtë komponent. Instalimi kryhet në pesë hapa:

1. klikoni skriptin "Ngarko";
2. klikoni "Pajtohem dhe filloni shkarkimin": një skedar me një shtesë .exe për sistemi operativ dritare;
3. pastaj "Ruaj" skedarin që rezulton dhe ekzekuto atë (duke klikuar dy herë me butonin e majtë të miut);
4. klikoni në butonin "Instalo";
5. pas përfundimit të procesit të instalimit, thjesht duhet të klikoni në butonin "Mbyll". Kjo do të tregojë që instalimi ka përfunduar.

Konfigurimi i skriptit

Konfigurimi kryhet përmes "Start" në "Paneli i Kontrollit". Pastaj hapeni Paneli i kontrollit. Ju do të duhet të çaktivizoni vetëm protokollet: TLS 1.1 dhe TLS 1.2. Është e lehtë për ta bërë: zgjidhni kutitë pranë tyre. Në te njejtën mënyrëçaktivizoni "Përdor formatin ClientHello të përputhshëm me SSL 2.0". Gjithçka është gati.

Shumë e shumë vite më parë, duke punuar si administrator në një nga ndërmarrjet qytet-formuese brendësia ruse, për herë të parë më duhej të merresha me konceptin " nënshkrim dixhital"(në tekstin e mëtejmë EDS).
Në atë kohë, tek krerët e menaxhmentit u rrënjos ideja se EDS është një nënshkrim i rregullt, i skanuar dhe i shtuar në të gjitha dokumentet që duhet të "nënshkruhen".

Le të hedhim një vështrim se çfarë është EDS dhe si funksionon.

Për të punuar me EDS, para së gjithash na duhet një certifikatë dixhitale dhe çelës privat.

Së pari, ne duhet të vendosim EDS nën dokument.
Instalimi i EDS kryhet në dy hapa:
1. Marrim dokumentin që duam të nënshkruajmë dhe llogarisim hash-in nga ky dokument. (Thjeshtimisht, një hash është një drejtim funksioni matematik konvertimi i një dokumenti me gjatësi arbitrare në një dokument me gjatësi fikse).
2. Më pas, ky hash i marrë kodohet me çelësin tonë privat.

Tani dokumenti, me EDS-in e bashkangjitur dhe certifikatën tonë, u dërgohet marrësve.

Pasi të kemi marrë dokumentin e nënshkruar, duhet të kontrollojmë nënshkrimin - a është i vlefshëm apo jo.
Verifikimi i EDS është disi më i komplikuar:
1. Marrim dokumentin nënshkrimi i të cilit duhet të verifikohet, llogarisim hash-in nga ky dokument.
2. Marrim certifikatën dixhitale të përdoruesit që ka nënshkruar dokumentin dhe e ka bashkangjitur Dokumenti EDS(i cili është hash-i i dokumentit origjinal i koduar me çelësin privat të nënshkruesit) dhe i deshifruar me çelësin publik.
Kështu, ne kemi dy hash - atë që kemi llogaritur vetë dhe atë që kemi marrë së bashku me dokumentin dhe deshifruam çelës publik nënshkruese.
3. Tani ne i krahasojmë këto hash. Nëse hash-et përputhen, atëherë nënshkrimi është i vlefshëm; nëse hash-et ndryshojnë, atëherë nënshkrimi është i pavlefshëm.

Si përfundim, ne përcaktojmë se çfarë na jep përdorim nënshkrim dixhital:
1. Pandryshueshmëria gjatë transmetimit ose ruajtjes - nëse dokumenti është ndryshuar, atëherë hash-i që ne llogarisim dhe që i është bashkangjitur dokumentit do të jetë i ndryshëm, prandaj nënshkrimi do të jetë i pavlefshëm, nga i cili mund të konkludojmë se dokumenti ka qenë ndryshuar;
2.

Për ta bërë të pamundur falsifikimin e një EDS, çelësi privat duhet të jetë në një kopje të vetme dhe vetëm pronari duhet të ketë akses në të. Kjo mund të bëhet duke përdorur kartat inteligjente, por kjo është një histori tjetër.

Problemi është si vijon.

Faqja përmban disa aplikacione, si dhe një ndërfaqe për menaxhimin e tij, të shkruar në HTML + JavaScript. Kërkohet të përcaktohet nga JavaScript që aplikacioni është i ngarkuar dhe gati për të punuar. Zgjidhja duhet të jetë SHUMË e besueshme - ndër-shfletues, që i përgjigjet mirë Internetit të ngadaltë, etj.

komentoj. Derisa apleti të ngarkohet, thirrjet nga JavaScript në metodat dhe/ose fushat e tij publike janë të mbushura me pamjen e një mesazhi shumë të shëmtuar diçka si kjo: " Kjo metodë mungon". Dhe apleti nganjëherë kërkon shumë më shumë kohë për t'u ngarkuar sesa vetë faqja. Për më tepër, disa gjëra ndonjëherë kanë kuptim të bëhen automatikisht (nga JavaScript) sapo të ngarkohet apleti - le të themi, jepni një komandë.

Problemi këtu nuk është aq shumë se nuk ka asnjë mënyrë për të kontrolluar nëse aplikacioni është ngarkuar tashmë, por se ka një bollëk mënyrash të tilla. Për shembull: onload për një applet, onload për një faqe, thirrja e një metode ose fushë të një appleti, informimi "aktiv" i faqes për ngarkimin e apletit me kod të veçantë Java nga brenda vetë apletit, etj. Dhe për t'u siguruar që këto metoda do të funksionojnë:
në çdo shfletues të mundshëm,
per te gjithe cilësimet e sigurisë në shfletues
kombinuar me çdo platformë të mundshme,
me të gjitha JRE-të,
nuk kam. Dhe për të marrë një besim të tillë është pothuajse joreale: ka shumë kombinime.

Më keq se kaq, këtu duket se është shumë e lehtë të “bëhesh shumë i zgjuar”. Për shembull, dje "luftova" me një gabim për një kohë të gjatë - në kompjuterin e dikujt tjetër (XP + MSIE + Java2), JavaScript gabimisht besoi se aplikacioni nuk ishte i ngarkuar, megjithëse gjithçka ishte në rregull në kompjuterin tim. Unë dyshoj se çështja është se më pas kam përdorur për të kontrolluar aksesueshmërinë e një thirrjeje për disa ndryshore publike të aplikacioneve (jo metodë!). Të gjithë shfletuesit në kompjuterin tim (gjithashtu XP) kur hyjnë në një variabël të tillë të nënngarkuar të apletit kthehen null dhe sapo të ngarkohet apleti, ata e kthejnë vlerën e tij. (Në të kundërt, thirrja e një metode në një aplikacion të nënngarkuar shkakton një gabim.) Kam frikë se në kompjuterin e dikujt tjetër, shfletuesi refuzoi të lexonte variablin publik. Qasja në variabla nuk është aspak një gjë e dukshme, duke punuar ndryshe nga shfletues të ndryshëm dhe JRE. Vetëm thirrjet e metodës janë të besueshme, por vetëm kur apleti është i ngarkuar.

Deri tani kam shkruar çifti i ardhshëm funksione:

Funksioni showMyErrorMessage(msg,url,line) ( if (window.errorMessage != null) alert(window.errorMessage); window.onerror = window.onerrorSave; kthe e vërtetë; ) Funksioni getApp(emri,notShowMessage) (window.errorMessage = null; var a = " gabim ndërsa duke hyrë në applet informacion për apleti \"" + emri + "\" Java."; var b = "Ndoshta, ky aplet nuk është ngarkuar saktë. Ju lutemi provoni ta rifreskoni këtë faqe."; if (notShowMessage==null || !notShowMessage) ( dritare .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("Nuk mund te aksesohet \"" + emri + " \" Java applet." + b); else alert("Nuk mund të qasem në informacionin e apletit për \"" + emri + "\" apleti Java." + b); ) kthej null; ) kthe aplikacionin; )

Përdoret një teknikë mjaft e lashtë (në teori, ndër-shfletuesi) për të shtypur mesazhet e gabimit përmes window.onerror. Gjithçka funksionon nën Mozilla 1.4, MSIE 6.0 dhe madje edhe nën Netscape 4.5 të lashtë, por, mjerisht, jo nën Opera 7.23 (shumë më popullor): kjo e fundit jep një mesazh rreth Gabim JavaScript. Është e nevojshme një thirrje për një metodë apleti - sepse pothuajse të gjithë shfletuesit (përveç Netscape) kthejnë me sukses një dokument jo null. Objekti Emri i aplikacionit sapo të lexohet TAG në faqe

Nga metodat e tjera të kontrollit, të gjitha llojet e ngarkimeve më shkaktojnë mosbesim - në kohën time (në shfletuesit e vjetër) shpesh më duhej të korrigjoja situatat kur onload refuzoi të punonte pa ndonjë arsye të dukshme, për shembull, kur shtypja "Refresh" për një faqe ose diçka tjetër. si ajo. Më e besueshme duket se është "aktiv" informimi i faqes - kur kodi Java i aplikacionit thërret JavaScript. Por këtu duket se është zgjidhja e vetme ndër-shfletuesi - showDocument në një dritare (ose kornizë) të veçantë, gjë që e bën zgjidhjen jashtëzakonisht të rëndë.

Ndoshta dikush do të sugjerojë një mënyrë të besueshme, mundësisht të publikuar dhe të njohur gjerësisht për të kontrolluar ngarkesën e aplikacionit?

Për Opera, meqë ra fjala, konstrukti try...catch funksionon mirë. Por vetëm i njëjti ndërtim, nëse nuk gabohem, do të çojë në një gabim sintaksor në MSIE të hershme, i cili ende duket se e kapërcen Operan në popullaritet. Si do të sigurohesh që mund të përdorësh try...catch? Kompilimi i kushtëzuar MSIE -

/*@cc_on @*/ /*@if (@_jscript_version >= 5) (përdor try..catch dhe gjëra të tjera të mira këtu) @*/ /*@end @*/

Si zakonisht, në Opera injorohet :(

Me sa duket keni parasysh paketën netscape.javascript.*?

Kjo zgjidhje nuk është e lëvizshme - nëse nuk gaboj, në MSIE me JRE 1.1.4 të integruar, kjo teknikë filloi të funksionojë vetëm diku nga versioni 5.5 ose edhe më i lartë. Unë kurrë nuk e kam përdorur këtë paketë - për shkak të intolerancës; ndoshta e kam gabim? Kam shkruar për këtë më lart: "këtu duket se është zgjidhja e vetme ndër-shfletuesi - showDocument në një dritare (ose kornizë) të veçantë, gjë që e bën zgjidhjen jashtëzakonisht të rëndë."

Unë zakonisht përpiloj aplikacione në JDK 1.1.6 (versioni më i hershëm i disponueshëm në arkivat e Sun); nuk ka një paketë të tillë.

Dhe nëse e rrethoni kopshtin, duke marrë parasysh që paketa netscape.javascript.* mund të mos ekzistojë, atëherë nuk do të dalë më mirë sesa, për shembull, të kontrolloni veçmas operën dhe të përdorni provoni...catch për të.

Ishte shumë kohë më parë :) Opsione:

1. Apleti ngarkohet në një kornizë, në metodën init() ngarkon një dokument me JS në një kornizë tjetër, duke thirrur metodat e tij, si:

boshllëk publik init()(
//....
getAppletContext().showDocument("js_page.htm", "nother_frame");
}
Një shembull nga viti 1998 - http://www.copris.com/optocontrol/home.htm - funksionon në IE5.5 dhe Mozilla 1.6 (bërë në ditët e NN3 dhe IE3) :)

1. Prisni për ngarkimin në një lak:

funksioni checkApplet() (
if (dokument && dokument["appletName"] && dokument["appletName"].isActive())
//Bej dicka
tjetër
setTimeout (checkApplet, 100);
}

isActive() është një metodë e klasës java.applet.Applet.

Alexey Ryumin i njohur si Xhuxhi[dosje]
Faleminderit shume. Por...

1. Sa për showDocument, unë tashmë kam menduar: "Por këtu duket se është e vetmja zgjidhje ndër-shfletuesi - showDocument në dritare e veçantë(ose kornizë), gjë që e bën zgjidhjen jashtëzakonisht të rëndë."

Fatkeqësisht, faqja ime nuk është e bazuar në kornizë për nga natyra, dhe është shumë e papërshtatshme të futësh korniza atje vetëm për hir të një aplikacioni. Dhe opsioni IFRAME nuk është ndër-shfletues - nuk do të jetë më i mirë se zgjidhja ime window.onerror.

Në fakt, tashmë aplikacionet e mia me struktura 3D janë të pranishme në disa nga faqet tona, dhe në të ardhmen do të ketë shumë më tepër faqe të tilla (të gjitha llojet e galerive të shembujve të strukturave, etj.). Në fakt, në faqen tonë, aplikacionet do të zënë afërsisht të njëjtin vend si fotot ( ): një ilustrim për tekstin, i cili mund të "përdredh" me miun në të njëjtën kohë. Dhe pranë çdo aplikacioni të tillë, ndoshta, do të ketë disa butona të thjeshtë kontrolli JavaScript: mirë, të paktën për të kthyer një imazh tredimensional të rrotulluar në pozicionin e tij origjinal.

Prandaj nevoja funksion universal si getApp im, i cili mund të vendoset në një skedar js të përfshirë dhe për të cilin nuk keni nevojë të rivizatoni faqet në korniza.

1. Por kjo është - më falni, e gabuar.

Ne po shkruajmë një test të thjeshtë.

...

Pas kësaj, ne e ngarkojmë këtë faqe përmes çdo Interneti jo të menjëhershëm, pasi kemi pastruar më parë cache MSIE. Siç mund ta prisni, derisa aplikacioni të jetë ngarkuar në të vërtetë (katrori gri), thirrja në isActive() gjeneron mesazhin e gabimit të mësipërm. Në të njëjtën kohë, thirrja në document.XXXX funksionon mirë, siç mund ta shihni duke ndryshuar kodin në

alarmi(dokumenti.XXXX);

Pasi objekti i faqes XXXX të jetë dhënë tashmë, shfletuesi lejon që objekti të aksesohet lirisht.

Vërtetë, këtu shfaqet një nuancë interesante. Shndërrimi i një objekti apleti në një varg prodhon rezultate të ndryshme në varësi të faktit nëse apleti është ngarkuar apo jo. Domethënë, nëse apleti është i ngarkuar, atëherë konvertimi i objektit DHTML në një varg jep rezultatin e thirrjes së "toString()" në aplet. Ideja është të shkruani një fjalë kyçe në metodën toString dhe të kontrolloni nëse kjo fjalë është e pranishme në vargun e dokumentit.emri i aplikacionit+"".

Do të ishte thjesht e mrekullueshme, shumë e thjeshtë dhe e bukur, madje funksionon edhe në Opera. Por - Mjerisht - këtë herë na zhgënjeu Mozilla-n. Tregon infeksion, budalla, pavarësisht nga fakti i ngarkimit. Kështu që nuk do të funksionojë ...

Tani për tani - më tregoni se si të "zbuloj" me besueshmëri se kemi të bëjmë me Opera moderne - më saktë, që provoni...kapni punë? Opera duket se e ka zakon të shtiret si shfletues të tjerë. Nëse zbuloni se try..catch funksionon, mund të telefononi një version të kodit me këto deklarata nëpërmjet eval - funksionon edhe nën Opera.

Më shumë për të njëjtën temë. Unë propozoj që zgjidhjet e mundshme të problemit të ndahen në dy grupe.

1. Procedura, në rast gabimi, mund të gabojë një applet të ngarkuar normalisht me një të shkarkuar. Ky grup përfshin të gjitha vendimet e bazuara në ngjarjet e ngarkimit dhe veprimet "aktive" të aplikacionit pas përfundimit të ngarkimit të tij (siç është hapja e një faqe në një kornizë të veçantë). Nëse nuk ndodh ngarkimi, ose nëse siguria e shfletuesit nuk e pengon apletin të hapë një dritare, ose nuk ndodh diçka tjetër e papritur, nuk do ta dimë kurrë në JavaScript që apleti është i ngarkuar. Çmimi i një gabimi të tillë është shumë i lartë: përdoruesi nuk do të jetë në gjendje të punojë dhe, me siguri, problemi nuk do të zgjidhet as duke rifilluar shfletuesin.

1. Procedura, në rast gabimi, mund të marrë një aplikacion të shkarkuar për një aplikacion të ngarkuar normalisht, por nëse aplikacioni është tashmë i ngarkuar, atëherë gjithçka është e garantuar të funksionojë. Funksioni im getApp i përket këtij grupi. Për një aplet të ngarkuar normalisht, metoda getAppletInfo thjesht duhet të funksionojë pa probleme (pasi apleti im e ka atë); edhe nëse nuk funksionon, nuk ka gjasa që aplikacioni të mund të përdoret fare nga JavaScript. Kostoja e gabimit në këtë rast është shumë më e ulët. Thjesht, ndonjëherë në rast problemesh (për shembull, probleme me internetin), përdoruesi do të marrë një mesazh gabimi "të egër" në JavaScript në vend të një mesazhi "të civilizuar" - ose asgjë nuk do të ndodhë fare nëse vizualizimi i mesazheve të tilla është i paaftë.

Nëse është e mundur, kufizohuni në zgjidhjet e llojit të dytë.

Diçka që nuk e kupton, e dashur.

Ju nuk mund të telefononi në mënyrë të qartë toString()! Objekti "applet" DHTML NUK ka metodën e tij toString, ai shfaqet vetëm kur ngarkohet klasa Java. Prandaj, një përpjekje për të nxjerrë
alert(document.PackingSpheresForDesign.toString());
kur apleti nuk është i ngarkuar rezulton në një gabim JavaScript, në MSIE tim është "Gabim i paspecifikuar".

Ju gjithmonë mund të thërrisni në mënyrë implicite toString, natyrisht, duke konvertuar një objekt DHTML në një varg. Dhe këtu, siç thashë, Mozilla sillet në mënyrë të shëmtuar: ajo kurrë nuk e quan apletin toString(), edhe kur apleti është plotësisht i ngarkuar. Dhe nuk është e dokumentuar askund që shfletuesi duhet të përdorë toString të klasës Java. Një zgjidhje që mbështetet në kontrollimin e paraqitjes së vargut DHTML të objektit Applet, padyshim që bie në kategorinë e parë: nëse një shfletues nuk dëshiron të thërrasë metodën toString, atëherë aplikacioni GJITHMONË do të konsiderohet i shkarkuar në atë shfletues dhe përdoruesi fiton nuk mund të punoj fare.

Si të siguroheni në JavaScript që shfletuesi është mjaft i mirë për të kuptuar konstruktin try...catch? Unë jam i prirur për të shkuar në këtë rrugë tani për tani.

Daniel Alievsky [dosja]
Jo, mirë, është e qartë se në MSIE thirrja toString() është një gabim, por shfletuesi është i lehtë për t'u përcaktuar në javascript. Nëse shfletuesi mozilla, thirrni toString() nëse jo, thjesht applet.

Sa i përket thirrjes së metodës toString në shfletues, me sa kuptoj unë, çdo objekt në javascript duhet të ketë një metodë toString, dhe nëse shfletuesi nuk e thërret këtë metodë në aplet, atëherë ka dyshime se madje është e mundur të thirret metodat e apletit në këtë shfletues - pavarësisht nga sjellja në këtë rast mozilla.

Me pak fjalë, së pari duhet të gjeni një shfletues të tillë dhe është e dëshirueshme që ai të jetë mjaft i përhapur, sepse përndryshe unë vetë mund të shkruaj shpejt një shfletues që do të sabotonte të gjitha përpjekjet për të përcaktuar ngarkesën e aplikacionit.

Epo, po. Thjesht nuk e mendova. Në të vërtetë, më duhet vetëm t'i referohem jo metodës getAppletInfo në funksionin tim, por metodës toString. Në MSIE, megjithatë, si më parë, do të ketë një gabim, por ai kapet në mënyrë të sigurt përmes window.onerror. Por në Opera - dhe në të gjithë shfletuesit që lejojnë thirrjen e toString në një aplikacion të nënngarkuar - nuk do të ketë fare gabime, thjesht toString do të kthejë ose një varg me një fjalë kodi nëse apleti është i ngarkuar, ose diçka si parazgjedhje. Në të njëjtën kohë, duket se nuk duhet të ketë një shfletues kaq të çuditshëm që një thirrje JavaScript në String për një aplikacion të ngarkuar normalisht të mos i referohet metodës së apletit me të njëjtin emër.

Duket si një zgjidhje e mirë. Faleminderit per ndihmen. Unë do ta testoj atë nën të gjitha llojet e shfletuesve të shtrembër si Netscape 3 - dhe do ta ofroj për FAQ.

Alexander Samoilov [dosja]“Sa i përket thirrjes së metodës toString në shfletues, me sa kuptoj unë, çdo objekt në javascript duhet të ketë një metodë toString, dhe nëse shfletuesi nuk e thërret këtë metodë në applet, atëherë ka dyshime se madje është e mundur të thirrni metodat e apletit në këtë shfletues ... "- këtu nuk ju kuptova fare, sepse vetëm MSIE më i njohur beson se objekti Applet nuk ka toString nëse aplikacioni nuk është i ngarkuar (për shembull, nëse shtegu i gabuar i klasës është specifikuar). Nuk pashë fare indikacione të qarta në dokumentacion se CDO Objekti JavaScript duhet të ketë këtë metodë. Nëse ka ndonjë - thesni gishtin, nëse jo e vështirë.

citat nga ndihma për JScript

Të Objekt përmbahet në të gjitha objektet e tjera JScript; të gjitha metodat dhe vetitë e tij janë të disponueshme në të gjitha objektet e tjera. Metodat mund të ripërcaktohen në objekte të përcaktuara nga përdoruesi dhe thirren nga JScript në momentet e duhura. Metoda toString është një shembull i një metode Object të ripërcaktuar shpesh.

prej tij, natyrisht, është e pamundur të nxirret pa mëdyshje një përfundim se për të gjithë interpretuesit e tjerë javascript kjo është bërë.

për sa i përket MSIE, nuk mendon se apleti nuk ka një metodë toString, ai mendon se ka ndodhur një gabim i papërcaktuar gjatë ekzekutimit të kësaj metode.

për shembull, nëse përpiqeni të thërrisni një metodë qëllimisht jo-ekzistente në një aplikacion, gabimi do të jetë i ndryshëm.

Dreqin! Do të qeshni, por MSIE + Java 2 NUK është i gatshëm të thërrasë toString() në një aplet të ngarkuar NORMALisht. Ai hedh vazhdimisht një gabim të papërcaktuar. Dhe me konvertimin e paracaktuar në një varg, përkatësisht, toString im i mbivendosur thjesht injorohet.

Ndoshta, sigurisht, kam diçka që nuk shkon me apletin - do të ishte e nevojshme, në teori, të bëhej një test i pastër. Por në çdo rast - nëse të paktën në aplikacionin tim është kështu, atëherë teknologjia është e gabuar.

Çfarë do të. Dje harrova të kontrolloja këtë situatë (kontrolluar nën Java 1.1.4). Sot vrava gjysmë ore në një defekt misterioz të faqes. Më keq, si një "efekt anësor" MSIE filloi të varej në heshtje kur hapte faqen (me sa duket për shkak të skripteve të mia të ndryshme ndihmëse). E tmerrshme.

U kthye në teknikën e vjetër me thirrjen getAppletInfo().

Pra, zotërinj, pres me padurim sugjerime të mëtejshme. Në veçanti - si të kapni Opera (për ta luftuar atë veçmas).

Vladimir Palant [dosja] Faleminderit. Është e mundur pervoistochnk nëse nuk e komplikon? (Unë mendoj diku në faqen e internetit të operës.)

Nuk do të doja aq shumë të zbuloja Operan sa të kontrolloja Versioni JavaScript që mbështet provo...catch - compatible with Mënyra e operës. Versioni i Microsoft i një kontrolli të tillë - përpilim i kushtëzuar - natyrisht, nuk funksionon nën Opera.

Në rastin më të keq, kontrolli i Opera është i mjaftueshëm: në këtë rast, ju mund (shpresojmë :-)) të telefononi toString në applet.

Daniel Alievsky [dosja]
pse të mos përdorni versionin javascript për të kapur mbështetjen e try catch

e vërteta në opera nuk kontrollohet

Daniel Alievsky [dosja]
Jo, opera.com rekomandon kontrollin nga agjenti i përdoruesit (http://www.opera.com/support/search/supsearch.dml?index=570) - IMHO një perversion. Është më e besueshme të kontrollosh kundër window.opera - asnjë shfletues tjetër nuk do ta mbështesë këtë veçori.

Opera ka mbështetur try/catch që nga të paktën versioni 4.0, kështu që mund të supozoni se e bën gjithmonë.

Ekziston edhe një ide tjetër - nuk e kam testuar ende. Qasja në vetitë e një objekti (veti) DHTML, me sa di unë, nuk bën kurrë një përjashtim. Nëse nuk ka një pronë të tillë, thjesht kthehet null. Do të ishte mirë t'i jepni apletit disa veti (për shembull, iAmLoaded=true boolean) dhe të kontrolloni nëse është vendosur. Me sa kuptoj unë, në rastin e Java 2, kjo nuk është aq e thjeshtë - nuk mjafton të kesh një fushë publike, duhet të deklarosh disa metoda get / set, siç duhet të jetë në JavaBeans (kam ende i pa studiuar dokumentacioni përkatës).

Sa teknikë e besueshme dhe ndër-shfletuesi mendoni se është?

Nuk e kuptova se çfarë ka të bëjë JavaBeans me të, për mendimin tim, qasja në pronat kryhet pa asnjë marrë / set. Por në çdo rast, ju mund të kontrolloni praninë e një metode, e cila është gjithashtu një veti për DHTML: if (typeof(applet.notifyAll) != "i papërcaktuar") . Por do t'ju duhet të kontrolloni vetë përputhshmërinë e shfletuesve ...

Vladimir Palant [dosja]
Ekziston një sugjerim i JavaBeans Introspection këtu: http://java.sun.com/j2se/1.4.2......loper_guide/compatibility.html
Siç e kuptoj, problemi ishte i përkohshëm: në kompjuterin tim në të gjithë shfletuesit dhe JRE, qasja në fushën publike funksionon mrekullisht. Për më tepër, është absolutisht e lehtë të shtosh një fushë publike "të vërtetë" të tipit boolean në applet, atëherë nuk ka nevojë të përdorësh truket më ekzotike si typeof(applet.notifyAll). (Meqë ra fjala, lloji i përmendur nuk funksionon për mua në MSIE as me 1.1.4 as me Java 2.)

Problemi është se më parë përdora vetëm një teknikë të tillë - duke kontrolluar ekzistencën e një fushe publike - dhe sapo hasa në një problem, dhe, padyshim, të atij lloji të parë shumë të pakëndshëm: fusha nuk u zbulua, aplikacioni u zbulua si shkarkoi dhe refuzoi plotësisht të punojë. Kjo ndodhi në 2 kompjuterë "të huaj" me një konfigurim krejtësisht normal (MSIE + Java 2, diçka si JRE 1.4.2_01), megjithëse gjithçka funksionoi në kompjuterin tim. Natyrisht, ndalova përdorimin e kontrollit në terren - pa rrezik.

Por ndoshta thjesht nuk e bëra sa duhet? Le të themi se nuk keni deklaruar metodat e marrjes/vendosjes "të stilit JavaBean"? Nëse nuk shoh një përshkrim të qartë të këtij problemi në dokumentacion, duke shpjeguar pse qasja në një fushë të rregullt publike nuk funksionon në disa shfletues dhe si ta bëj atë në mënyrë korrekte, sigurisht që nuk do të rrezikoj të përdor verifikimin e fushës - kostoja e gabimit është shumë lartë.

Kapja e mesazhit të gabimit është gjetur se funksionon edhe në Netscape 3. Por pak e gabuar: ky shfletues i lashtë thërret procedurën e shfaqjes së mesazhit në mënyrë asinkrone me rrjedhën kryesore të kodit JavaScript, duke rezultuar në gabime delikate. Derisa e rregullova. Natyrisht, askush nuk ka nevojë për përputhshmëri me Netscape 3, por është alarmante që teknika (duke thirrur metodën e apletit, ose toString për Opera, me përgjimin e gabimeve) kërkon korrigjimin "i ri" për pothuajse çdo klasë shfletuesish: (Me sa duket, në fund të fundit teknika është e lakuar, por çfarë lloj teknike është "e drejtë" nuk është ende e qartë.

Me Netscape 3.0, kënga ishte krejtësisht ndryshe. Ky shfletues në përgjithësi nuk ishte shumë miqësor me kërkesat si document.xxxx, ku xxxx është emri i aplikacionit. Edhe për një aplet vërtet të ngarkuar, ai jepte një sërë gabimesh kur u bë kjo akses:
Nuk mund të pasqyrohet apleti "(null)": nuk është ngarkuar ende
(Gjëja qesharake është se kjo ndodh edhe me kontrolle të tipit "if (document.getElementById != null)...".) Lufta kundër kësaj është shumë e thjeshtë. Mjafton të kornizoni çdo thirrje në çdo dokument.xxxx me kod si:
var onerrorSaveLocal = dritare.onerror;
window.onerror = null; // - shmangia e një përjashtimi të pasaktë në Netscape Navigator 3
varv = dokument.xxxx;
window.onerror = onerrorSaveLocal;

Në të njëjtën kohë, si në Netscape 4, dhe në "shfletuesin" e integruar nga JavaBuilder, kur aplikacioni document.appletname nuk ngarkohet, ai thjesht kthehet null.

Në përgjithësi, kalova pak kohë dhe korrigjova procedurën time nën të gjithë shfletuesit që mund të "arrija" - duke përfshirë versionet e mëparshme MSIE. Ja çfarë ndodhi:

Funksioni showMyErrorMessage(msg,url,line) ( if (window.errorMessageA != null) alert(window.errorMessageA+"(Mesazhi i gabimit të sistemit: "+msg+")"+window.errorMessageB); window.onerror = window.onerrorSave; kthen true; ) funksionin getApp(emri,notShowMessage) ( // Për pajtueshmërinë me këtë funksion, të gjitha aplikacionet Java duhet të anashkalojnë metodën "toString()" // dhe të kthejnë një varg që përmban nënvargun "Aplet Java i ngarkuar me sukses" si rezultat i tij Windows .errorMessageB = "Ndoshta, ky aplet nuk është ngarkuar saktë." + "Ju lutemi prisni derisa të ngarkohet plotësisht, " + "ose ju lutemi provoni ta rifreskoni këtë faqe."; ) var opera = window.opera != null; nëse (window.onerrorSave == null) window.onerrorSave = window.onerror; var app = null; var appInfo = null; var onerrorSaveLocal = window.onerro r; window.onerror = null; // - shmangia e një përjashtimi të pasaktë në Netscape Navigator 3 // ("Nuk mund të pasqyrohet apleti "(null)": nuk është ngarkuar akoma") // shfaqej ndonjëherë gjatë qasjes në aplikacionin e aplikacioneve të ngarkuara saktë = eval("dokument."+emri ); window.onerror = onerrorSaveLocal; var systemErrorMessage = null; /*@ [email i mbrojtur]*/ /*@if (@_jscript_version >= 5) provo ( // disa MSIE (për shembull, MSIE 5.0) nuk e kuptojnë kapjen e bazuar në një gabim @else @*/ window.onerror = showMyErrorMessage; // kapja e përjashtimeve ndërsa thirrja e metodës joekzistuese /*@end @*/ appInfo = app == null? null: // një rast i shfletuesit Netscape opera? app.toString(): // MSIE + Java2 nuk mund të thërrasë aplikacionin e aplikacionit toString app.getAppletInfo (); // MSIE dhe Mozilla (por jo Opera) do të kenë një përjashtim këtu /*@if (@_jscript_version >= 5) ) catch(e) ( systemErrorMessage = e==null || e.description==null? "gabim i panjohur": e.përshkrim+""; ) @else @*/ window.onerror = dritare.onerrorRuaj; window.onerrorSave = null; /*@end @*/ if (aplikacioni == null || systemMessage Gabim != null || appInfo == null || (opera && (appInfo+"").indexOf("Aplet Java u ngarkua me sukses")==-1) ) ( if (window.errorMessageA != null) ( if (app == null) alarm ("Nuk mund të gjendet \"" + emri + "\" Java applet." + window.errorMessageB); përndryshe nëse (systemErrorMessage != null ) alert("Ndodhi një përjashtim gjatë qasjes në informacionin e apletit për aplikacionin Java \"" + emri + "\". (Informacioni i përjashtimit të sistemit: " + systemErrorMessage + ")" + window.errorMessageB); përndryshe nëse (appInfo == null ) alert("Nuk mund të qasem në informacionin e apletit për apletin Java \"" + emri + "\"." + window.errorMessageB); else alert("Nuk mund të telefonoj \"" + emrin + "\" apletin Java." + dritare .errorMessageB); ) kthen null; ) kthe aplikacionin; )

Si zakonisht, MSIE dha një maksimum problemesh. E rëndësishme: MSIE 5.0, siç rezulton, refuzon të bllokojë mesazhet e gabimit përmes window.onerror. Më duhej të shkruaja një degë me përpilim të kushtëzuar dhe të provoja..kapja posaçërisht për MSIE-në "kapriçioze". Në pamje të parë, try..catch duket se është zgjidhja më e besueshme, kështu që ka kuptim të plotë ta përdorni atë në familjen më të njohur të shfletuesve. Në të njëjtën kohë, në MSIE 4 (ku nuk ka try..catch), si dhe në Mozilla, bllokimi i gabimit përmes window.onerror vazhdon të funksionojë. Opera përdor një thirrje toString dhe kontrollon për një "fjalëkalim" brenda rezultatit. Gjatë rrugës doli gjithashtu që në MSIE 4 është më mirë të mos përpiqeni të hyni në applet nga para shkarkimit - mund të ketë gabime.

Madje arrita te MSIE 3.0 :-) Atje, duket se procedura ime nuk funksionoi, megjithëse, ndoshta, çështja këtu është se klasat e mia janë përpiluar në një mënyrë të papajtueshme me Java 1.0.2, dhe nuk kam dëshirë ta mbaj përputhshmëri e tillë.

Tani kam një kërkesë të madhe për të gjithë të pranishmit. Ju lutemi provoni këtë procedurë me disa aplikacione në të gjithë shfletuesit tuaj. Për shembull, a funksionon kjo në Mozilla/Opera Unix, apo Macintosh? Nëse në të gjitha variantet e Windows + MSIE? Po më shumë versionet e hershme Opera?

Kam testuar në shfletuesit e mëposhtëm:
Windows XP: MSIE 6.0 me Java 1.4.2 dhe Java 1.1.4, Mozilla 1.4, Opera 7.23, Netscape 4.5, Netscape Navigator 3.0;
Windows NT 4.0: MSIE 5.0 me Java 1.4 dhe Java 1.1.4, Netscape 4.5, Netscape Navigator 3.0;
Windows-95: MSIE 3.0 (Java 1.0.2), Netscape 4.5.

Mënyra më e lehtë për të testuar është duke specifikuar një rrugë qëllimisht të gabuar për apletin në faqe (dhe, për krahasim, atë të saktë) - për mendimin tim, kjo është mjaft e ngjashme me situatën kur appleti nuk u ngarkua. Nëse gjithçka është në rregull, atëherë, në teori, procedura meriton të vendoset në FAQ.

Në këtë faqe, butoni "Merr informacionin e JVM" (duke përdorur funksionin e mësipërm) duhet të aktivizohet sapo të ngarkohet aplikacioni ose "të betohet" derisa të ngarkohet.

(Meqë ra fjala, kjo teknikë nuk funksionon në MSIE 3.0 - në versionin tim 3.02, JavaScript refuzon të bëjë asgjë nëse aplikacioni nuk është i ngarkuar. Zoti e bekoftë.)

• Platformat: Të gjitha platformat
• Versionet Java: 7.0, 8.0

Kur lëshoni një aplikacion ose aplikacionet Java Shfaqet një kuti dialogu e paralajmërimit të sigurisë:

Të bllokohet funksionimi i komponentëve potencialisht të pasigurt?

Mjedisi Java zbuloi komponentët e aplikacionit që mund të tregojnë praninë e rreziqeve të sigurisë. Kontaktoni shitësin e aplikacionit dhe sigurohuni që të mos ketë përpjekje të paautorizuara për akses.

Aplikacionet dhe aplikacionet e nënshkruara Java Web Fillimi që përmban komponentë të nënshkruar dhe të panënshkruar mund të jetë potencialisht i pasigurt nëse kodi i përzier nuk është përdorur qëllimisht nga shitësi i aplikacionit. Duke filluar me Java SE 6 Update 19, kur punoni me një program që përmban komponentë të nënshkruar dhe të panënshkruar, shfaqet një kuti dialogu paralajmëruese.

ZGJIDHJE

Nëse klikoni butonin në kutinë e dialogut të sigurisë po, nisja e komponentëve potencialisht të pasigurt do të bllokohet, pas së cilës programi mund të përfundojë. Nëse shtypni butonin Jo, aplikacioni ose aplikacioni do të vazhdojë të funksionojë.
Paralajmërimi shfaqet si parazgjedhje, por ka opsione për të ndryshuar këtë cilësim.

Mënyra se si trajtohen programet me kod të përzier mund të konfigurohet duke përdorur Panelin e Kontrollit Java.

Gjetja e panelit të kontrollit Java