čtvrtek 17. dubna 2003

Odkazy - atribut onclick a přístupnost stránek

Pod tímto trochu neštastným nadpisem se budu snažit ukázat korektní způsob jak správně ošetřit otevření nového okna za využití klientského skriptování. Pro dokreslení dodám, že se jedná o případy, kde není možno využít atribut target, který není například v XHTML povolen.

Mnohdy nastane potřeba otevírat odkaz do nového okna, dúvodů k tomuto kroku je několik a není cílem tohoto příspěvku obhajovat jednu či druhou stranu brojící pro a proti. Cílem je ukázat postup korektní registrace a zpracování události onclick odkazu. Většinou se uvádí následující zápis.

<a href="foo.html" title="popis odkazu" onclick="bar(this.href);return false;" hreflang="cz" lang="cz" xml:lang="cz">

Výše uvedený zápis je předepisován jako ukázkový pro použití. Ve stručnosti si můžeme schrnout to nejdůležitější. Události onclick jsme zaregistrovali ovladač ve funkci bar, které jsem v argumentu dali obsah atributu href a jako návratovou hodnotu jsme vrátili false.

Co skrývá kliknutí na odkaz

Při kliknutí na daný odkaz se nejprve předá řízení registrovanému ovladači události(ten otevírá nové okno) a po jeho vykonání se vrátí hodnota false. Tím je zaručeno, že se neprovede vlastní odkaz v těle atributu href. Pokud někdo nemá zapnuté klientské skriptování nebo ho má v určité míře omezené provede se vlastní href a ovladač registrovaný na onclick se nevykoná.

Problémy na obzoru

Zda se, že je všechno ošetřené. Uživatelé bez nebo s omezeným klientským skriptováním jsou obslouženi standardně atributem href. Zdání klame, v naší konstrukci jsme úplně pozapomněli na případ kdy není možno okno otevřít nebo jeho otevření selže. Tato situace může nastat vlivem několika faktorů: blokovač nových oken, hlidač instancí prohlížeče, nefunkčnost skriptu, prohlížeč vůbec nemusí podporovat nové okna(alternativní zařízení).

Pokud nastane jedna z výše uvedených variant, ovladač události se sice provede nicméně požadované otevření stránky v novém okně se neuskuteční a uživatel tak nemá stránku na níž vede odkaz dostupnou. Po ovladači se ihned provede vrácení hodnoty false, které zamezí provedení atributu href ikdyž bychom v takovémto případě jeho vykonání uvítali.

Možnosti řešení

Ač se to na první pohled nezdá řešení neleží nijak daleko od původního. Při otevření nového okna, je třeba toto okno otestovat a pokud je okno korektně vytvořeno a reference na něj platná, nemusí se již vykonávat href. V případě potíží vrátíme hodnotu true, která zaručí provedení atributu href. Modelový příklad pak vypadá takto

<a href="foo.html" title="popis odkazu" onclick="return !bar(this.href);" hreflang="cz" lang="cz" xml:lang="cz" >

      
  <script type="text/javascript" >
    .
    .
    .  
  function bar(url){
    wasOpen  = false;
    win = window.open(url);    
    return (typeof(win)=='object')?true:false;
  }
 

Odkaz na nové okno jsme si uložili do proměnné win, tu posléze otestujeme a pokud se povedlo otevření, vrátíme jako návratovu hodnotu funkce true. V ovladači se pak negací vrátí hodnota false, která zamezí provedení atributu href. Pokud by se okno nepovedlo otevřít je vrácena hodnota false a ve výsledku se provede atribut href.

Pro lepší otestování, můžeme pro kontrolu například otestovat URL nově otevřeného okna apod. a nemusíme se jen spoléhat na kontrolu datového typu. Pro pořádek a na obranu prohlížečů jako je Mozilla 1.0 a Internet Explorer je třeba dodat, že při vnitřní chybě běhu klientského skriptu se provádí href standardně.

pondělí 14. dubna 2003

Gratulace - nový kodér na světě

Dnes 14.4.2003 se v Českých Budějovicích, narodil prvorozený syn mého kolegy a kamaráda Rudolfa "Kročka" Pischka. Malému Rudánkovi přeji hlavně hodně zdraví a zdraví a doufam, že se štastná rodinka s přírustkem brzo ukáže. Ještě jednou zdravim celou rodinu a gratuluji, nadarmo se neříka ...Kdo umí ten umí a kdo neumí ten čumí

Atrise HTML lock - špatný vtip na Intervalu

Už, už se zdálo, že doba nekvalitních článku via. klientské skriptování, server Interval minula. Jako vytažení pověstného kostlivce se tak jeví článek se zavádějícím názvem Bezpečné HTML stránky. Neznalý člověk by si mohl pod tímto nadpisem představit ledascos, protřelejší webdesigner/kodér se jen otřepe a já zakroutím hlavou.

Z principu je funkčnost poskytovaná programem Atrise HTML lock nedobrá. Ze dvou důvodů snaží se řešit neřešitelné a zároveň tak činí stránky nepoužitelné. Předem je třeba si uvědomit, že HTML je ze své podstaty jazyk popisný, vyjadřuje informace v určité struktuře tak, aby mohly být interpretovány v člověku srozumitelné a přívětivé podobě. Z výš uvedeného tak plyne, že ke klientu se vždy do prohlížeče dostane ve své nahé kráse. Metody, které popisuje článek a plní program jsou jen jakýmisi berličkami. Jeden a tentýž klíč slouží, jak pro zakódovaní tak pro dekódování zdroje. Článek, by měl spíše osvětlit klady a zápory takového řešení a nehledat pokoutné cestičky jak ospravedlnit pouze určitý úhel pohledu.

Nuže program jsem si stáhnul a začal testovat. Udělal jsem základní testovací stránku, kterou jsem daný program otestoval.


<!DOCTYPE html PUBLIC "-//W3C/DTD HTML 4.01 Transitional//EN">
<html>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1250" />
<head>
<title>Pokusná stranka</title></head>
<body>
<p>Ahoj světe, jsem první zašifrovaná stránka</p>
</body>
</html>

Analýza výsledného kódu

Opravdu jsem se těšil na výslednou stránku, která z programu vyleze. Zajímalo mě hlavně jak je řešena dekódovací funkce a výsledný zdrojový kód. Program mě opravdu nezklamal v tom špatném slova smyslu.

Svévolná změna kódování

První, co mě zarazilo při prohlížení výsledné vygenerované stránky, byla změna kódování z původního windows-1250, udělal program iso-8859-1. Stránky by se tak stalý absolutně nečitelnými, pokud bychom ručně nelaborovali s nastavením kódování v prohlížeči.

Deratizace DOCTYPE a nevalidní kód

Nuže pustil jsme se do luštění výsledného zdrojového kódu. Programu se zřejmě nelibí použitý DOCTYPE takže ho ve výsledku pro jistotu ani nezařadil, snad aby se to některým prohlížečům nepletlo. S tímto problémem souvisí i tag script. Ve výsledku obsahuje deprecated atribut language, pokud by původní stránka byla v XHTML, tento atribut by způsobil nevalidní kód, přitom řešení se nabízí ve formě atributu type. Z výše uvedeného plyne, že program naprosto ignoruje zvolené DTD dokumentu a vždy natvrdo dosazuje předem danou definici. Pro jistotu jsem, jsem vzal uhodní stranu Dagblogu, která používá DTD XHTML 1.0 Strict a výsledek byl naprosto stejný.

Při debuggování dekódovací funkce jsme zjistil, že původní stránka je tisknuta na výstup komplet celá. Autoři si nedali ani námahu, nechat meta tagy puvodní a svůj kód jen vlepit do těla. Takhle se do těla stránky(tagu body) znovu tiskne doctype, a všechny tagy počínaje kořenovým html.

Princip šifrovaní

Program má sice výstražnou hlášku, že ochrana takovýmto způsobem je lehce prolomitelná, nicméně mě střeva skriptu zajímala. Na první pohled je vidět, že se vše točí kolem dvou polí t a h. V poli h je uschována zakódovaná stránka v poli t jsou pak jednotlivé znaky sady iso-8859-1(úplně všechny). Podle části zvoleného hesla, konstanty 44 a části šifrovaného kódu se pomocí logického operátoru XOR spočte odpovídajíci pozice znaku v poli t. Tímto způsobem se pokračuje do sestavení celého řádku.

Použitím debuggeru chudých(tohle spojení mám opravdu rád) alias funkce alert není problém zjistit výsledný zdrojový kód. Funkci alert umístíme v podmínce testující proměnnou c na rovnost s číslem 13 a necháme si vypsat obsah proměnné s a máme výsledek tisknoucí se pomocí document.write do výsledné stránky.

Závěrečné resume

Výhody
  • Odradí pár potenciálních "zkoumačů-začátečníků"
Nevýhody
  • funkčnost pouze se zapnutým klientským skriptováním
  • změna kódování - pro stránky s českými znaky nepoužitelné
  • odstranění DOCTYPE - je použita vlastní velice špatná šablona
  • výstupní nevalidní kód
  • výsledný dokument postrádá jakékoliv logické členění
  • naprostá žádná ochrana proti trochu zkušenějšímu uživateli
  • indexace takovéhoto dokumentu, výhledávaní apod.
  • při větší rozsáhlosti dokumentu se zobrazení stránky výrazně prodlouží

Pokud pomineme fakt, že výsledný kód by sice plno uživatelů odradil nicméně pro trochu zkušenějšího kodéra by nebyl problém se výsledku dopátrat. Z výše uvedeného vyplývá, že program je opravdu nepoužitelný a nemá cenu se jím zabývat. Z celého řešení mám pocit ledabile odvedené práce jak z hlediska produktu Atrise HTML lock tak z článku. Kdyby si dal autor článku trochu prác, tak by zřejmě dospěl ke stejnému zjištění. Snaha o skrytí zdorjového kódu je marná a zbytečná a jde proti většině základních pravidel použitelnosti a dostupnosti.