Author: admin

Firebug – pohodlný vývoj webových aplikací

Při vývoji webových aplikací potřebuje vývojář nástroj, který by mu pomohl interaktivně zasahovat do zobrazených stránek, měnit CSS styly či pracovat a zadávat příkazy javascriptu. Firebug je právě tímto nástrojem, který jsem si, jakož to programátor, velmi oblíbil.

Co je Firebug

Firebug je doplňek do stále oblibenějšího internetového prohlížeče Mozzily Firefox, který umožňuje interaktivně zasahovat do zobrazených stránek a měnit tak obsah stránek, grafiku v podobě CSS, či testovat Javascriptové funkce. Tímto způsobem pomáha vyvojáří nacházet chyby ve vývoji a umožňuje tyto chyby odstraňovat.

Instalace Firebugu

Firebug je určen pro Mozzila Firefox (od verze 2.0) a je možné si jej zdarma stáhnout přímo ze stránek dopňků pro firefox.

Pohled do nitra „ohnivého broučka“

Po úspěšné instalaci se v pravém dolním rohu zobrazí ikona Firebugu v podobě brouka. Firebug je standardně vypnutý (ikona nesvítí, je šedá), proto je nutné na tuto ikonu poklepat a povolit jej.  Po jeho zapnutí je možné se v okně přepínat mezi jednotlivými záložkami, kdy v každé je možné upravovat část (řekněme použitou technologii) webové stránky.

Konzole

V této záložce je možné nalézt velmi detailně zobrazené chybové zprávy JavaScriptu. Které je možné si rozkliknout a okamžitě přejít na řádek, ve které se stala chyba.  Tato konzole taktéž zobrazuje informativní zprávy celé aplikace, mimochodem se zde můžeme dočíst, že například použití nějakých funkcí javascriptu je zastaralé a nemusí fungovat na novějších prohlížečích.

Html

Zde je možné si zobrazit HTML kod stránky, který je výborně rozčleněn do jednotlivých sekcí (tágů) stránky a jednoduše si takhle procházet celý strom HTML dokumentu. Po najetí na jednotlivý prvek (tág) HTML dokumentu se na stránkách tento element barevně označí. To je velmi dobrá vlastnost, kdy je možné tímto způsobem krásně hledat chyby v zobrazování dokumentu.
Po přepnutí do režimu úprav je možné přímo zasahovat  a interaktivně upravovat HTML dokument, kdy okamžitě vydíme výsledek své práce přímo na stránkách prohlížeče.

CSS

Z názvu je patrné, že zde je možné přehledně procházet kaskádové styly zobrazeného dokumentu. Noční můra každého webového vyvojáře je umísťování jednotlivých prvků do designu celého webu. Tento nástroj tuto noční můru alespoň trošičku zahání, kdy je možné, zase interaktivně, měnit jednotlivé elementy kaskádových stylů a přitom vidět, co to udělá se stránkami.
Skripty
Záložka, která zobrazuje JavaScript, který je používán na webové stránce.  Nelze přímo skripty měnit, ale je zde možnost vytvořit zde tzv. break point, a tím pomoci při debugování skriptu, k čemuž také pomáhá levý panel, kde je možné přímo vytvářet příkazy javascriptu a ty také spuštět, přičemž si okno uchovává informace, které daná funkce, či příkaz provedl, a je možné v něm pohodlně listovat. Tak například, po zadání příkazu document.getElementsByTagName(„body“), vyběhnou všechny metody a vlastnosti pro daný element.
Síť
Záložka, ve které lze nalézt veškeré dotazy a odpovědi ze serveru v pořadí, v jakém přicházely do prohlížeče.  Je možné si každý dotaz rozkliknout a zobrazit jednotlivé hlavičky dotazu, i odpovědi. Je zde možnost kontrolovat jednotlivou odezvu ze serveru na každý požadavek prohlížeče.

Závěrem

Firebug je velice dobrým nástrojem pro každého webového vyvojáře, ve kterém je možné si  HTML dokument stránky do detailu rozpitvat, a nalézt a taktéž ihned opravit veškeré chyby, ať již chyby zobrazování, nebo chyby JavaScriptu. Jen škoda, že něco takového nefunguje pro Internet Explorer, kde dohledat se chyby JavaScriptu je složitější, než najít jehlu v kupce sena!!!

CAPTCHA

Captcha je (a co jsem hledal tak snad i jediná) vhodná technika, která dokáže odfiltrovat uživatele od automatického robota při odesílání formulářů v internetových aplikacích. Captcha se na webu liší svým zobrazením, někdy se jedná o obrázek, o zvukovou nahrávku, či otázku, na kterou je nutno odpovědět. Standardně ve svých aplikacích používám jednoduchou obrázkovou Captchu, u které jsem předpokládal, že je proti robotům neprolomitelná. Můj zjevný omyl se projevil před několika dny, kde se najednou na určitém webu v diskuzi začaly objevovat příspěvky s odkazy na „hanbaté“ stránky. Samozřejmě vím, že se spamoví roboti snaží různými technikami Captchu obejít, ovšem netušil jsem, že se tak budou snažit u okrajových webů, kde je přístupnost nějakých pár set lidí denně. Zkusím Vám tedy letmo popsat, jak jsem se Spamem bojoval a nakonec i uspěl. Snad Vám to pomůže při Vašich projektech a již nebudete zbytečně zkoušet kousky, které jsem zkoušel já.
Jak už jsem psal výše, netušil jsem, že by se spamový robot snažil prolomit Captchu na webech s přístupností do jednoho tisíce lidí denně. Proto, když začaly chodit spamové zprávy do diskuze na jednom webu, jsem si  nemohl připustit, že je to zrovna nevhodnou  obrázkovou Captchou. Na tomto webu byla implementovaná CAPTCHA, která za pomocí JavaScriptu odstraňovala nutnost uživatele vkládat požadovaný kód (psal jsem o tom v článku Používejte geniální CAPTCHA techniku), proto jsem si nejprve myslel, že daný robot umí JavaScript a tím pádem se vždy do políčka pro Captcha doplní daný kód. Trošku jsem proto upravil skript, který nyní čekal 10 sekund před vyplněním Captcha kódu do políčka. Vycházel jsem z toho, že by robota nenapadlo čekat nějakou dobu na odeslání daného formuláře. I když se zdála úvaha správná, toto opatření samozřejmě nepomohlo a Spam se i nadále objevoval ve velkém množství.
V tento moment jsem si již myslel, že „geniální CAPTCHA pomocí JavaScriptu“ je neúčinná a proto jsem JavaScriptovou funkcionalitu z webu smazal, takže tam zůstala standardní, viditelná, obrázková CAPTCHA s nutností uživatele vyplnit požadovaný kód.

Ovšem když se i třetí den objevily odkazy na „hezké holky“, má třetí a konečně správná taktika pro boj se SPAMem byla nakonec úspěšná. A to aktualizace CAPTCHA, respektive aktualizace kódu pro generování CAPTCHA obrázku, který ve výsledku vypadal pro člověka méně čitelný, přesto proti robotům velmi úspěšný. Když jsem ještě k tomu přidal JavaScriptovou funkcionalitu, dostal jsem se znovu tam, kde jsem chtěl: neotravuji uživatele vyplňováním CAPTCHA kódu do políčka a zároveň je daná ochrana (tedy prozatím) úspěšná i před útokem robotů.
Při tomto boji se SPAMem jsem se naučil pár věcí:
Žádná ochrana proti SPAMu není stoprocentní a její procentní úspěšnost při častém používání velice rychle klesá k nule.
Když už se někdo protlačil přes ochranu, vždy aktualizuj jádro problému, v tomto případě obrázek CAPTCHA

A rada na závěr: i když se Vám jako programátorovi jeví Vaše CAPTCHA jako dokonalá barikáda před útokem SPAMů, vždy ji po nějakém čase aktualizujte, neboť SPAMoví roboti „nikdy nespí“.

Bezpečnost webových aplikací

Bezpečnost webových aplikací je mnohdy podceňovaná, přitom tyto aplikace mohou sdílet velmi důvěrná data o lidech, kteří aplikace používají. Ať již se jedná jen o jména a emaily našich zákazníků, tyto informace v jistých rukách mohou představovat velmi vysoké riziko zneužití. Je nutné si uvědomit, že bez dostatečného zabezpečení těchto dat se vystavujeme riziku nejen zneužití osobních informací našich zákazníků třetími osobami, ale také znevážení našich projektů a možná i soudních žalob ze stran zákazníků o vydání důvěrných dat třetím osobám.
Množství útoků na webové servery neustále roste, přičemž se mění i taktika útočníků. Na těchto internetových stránkách představím nejznámější typy útoků a možností jejich obrany (pokud je u daného typu útoku vůbec nějaká možnost obrany).

Cross site scripting

Hojně používaná metoda útočníků, kdy pomocí JavaScriptu dokáží ovládnout celý systém webové aplikace. Tato metoda těží z nedbalosti programátorů, kteří nedokonale zabezpečili vstupy a výstupy uživatele a dovolili mu vytvořit kód JavaScriptu a ten navíc ještě na svých stránkách spustit. Útočník tak může ovládat aplikaci a vytvářet podvržené stránky nic netušícím uživatelům. Co je však ještě horší, je možné tímto způsobem zjistit SESSION ID (jedinečný identifikátor uživatele) a následně se vydávat za právoplatného uživatele. Důsledky mohou být katastrofální jak pro uživatele webové aplikace, tak i pro administrátora aplikace, jelikož není moc velký problém tímto způsobem vstoupit do administrace aplikace a provádět různé operace za administrátora.

Možnosti obrany

Je nutné si uvědomit, že veškeré vstupy uživatele mohou být potencionálně nebezpečné. Ať již se jedná o vstupy na základě formulářů zaslané metodami POST a GET, tak i vstupy, u kterých přímo není jasný původ, mezi něž zahrnujeme COOKIES, či hlavičky jednotlivých požadavků (HEAD). Vývojář proto musí veškeré vstupy uživatele kontrolovat a filtrovat na základě toho, co chce od uživatele získat. Pokud od uživatele žádáme jméno a heslo pro přihlášení, určitě mu nedovolíme, aby do políček zadal nějaký JavaScriptový kód. Pokud zadá, musí aplikace tento kód odstranit a nedovolit jeho spuštění a to například tím, že od zadaných hodnot odstraníme veškeré HTML značky (tím odstraníme i HTML značky pro uvozování JavaScriptových kódu <SCRIPT></SCRIPT> a tím znemožníme spuštění kódu) a necháme jen čistý text.
Někdy je vhodné dovolit uživateli, aby mohl zadávat i HTML značky pro například formátování textu při vkládání článků. V takovém případě musí vývojář filtrovat takové značky HTML,  které mohou být potenciálně nebezpečné. Problém je, že kromě značek <SCRIPT></SCRIPT> mohou být nebezpečné i značky, které se na první pohled jeví, jako bezpečné, např. značka <IMG>. Tato nepárová značka umožňuje vkládat obrázky do HTML stránky, avšak jako každá značka může obsahovat i vytvoření obsluhy událostí a tu navázat na JavaScriptový kód. Např. <img onload=”alert(‘ahoj’)”/> vytvoří obrázek, avšak ihned po načtení obrázku se spustí nebezpečný kód JavaScriptu (v tomto případě jen zobrazí hlášku “ahoj”).
Pro zamezení těchto neoprávněných škodlivých skriptů je nutné vytvořit filtrovací funkci, která bude procházet veškerý text od uživatele tak, jako to například dělá internetový prohlížeč, a odstraňovat nebezpečné značky, či vlastnosti značek. Problém je, že pokud uživatel zadá např. <scr<script>ipt>, tak po odstranění <skript> vznikne <skript> znovu a útočník může útočit dál. Proto je důležité procházet filtr několikrát, dokud není text od značek plně odfiltrován.

Závěrem

Není přímo jednoduché se bránit cross site scriptingu. Ovšem vývojář musí udělat vše proto, aby se útočník nemohl dostat k citlivým údajům uložených na serveru. Je proto nutné řádně kontrolovat a filtrovat veškeré požadavky přicházející od uživatele a předkládat mu stránky bezpečné stránky bez cizího skriptu.

autocomplete=”off” – firefox již nepodporuje, jak to obejít?

Firefox od nějaké novější verze již nepodporuje u inputu autocomplete=”off”. Někdy je však zapotřebí, aby prohlížeč automaticky nedoplňoval data do políčka ze svojí cache paměti. Jednak je to zapotřebí u políček pro zadání hesla, kdy nechceme aby se hesla automaticky doplňovala (a tím pádem každý, kdo má přístup k tomuto počítači, aby se jednoduše nedostal tam, kde nemá co dělat) a také u určitých formulářů, kdy po odesílání a následném redirektu zpět na formulář nechceme, aby byly hodnoty v inputu stejné, jako byly před odesláním na server.

Existuje však jednoduchá pomoc, vytvořil jsem tento skript, který právě autocomplete=”off” plně nahrazuje ( a funguje ve všech prohlížečích stejně – za předpokladu, že existuje knihovna JQUERY):

$( document).ready(function () {

$(‘input[type=”password”][autocomplete=”off”]’). each(function () {

var $this = this ;

$ (‘<input>’ ).attr({
 type : ‘password’
 }) .keyup (function () {
 $($this). val($(this).val());
 }) .insertAfter( this);

$ (this ).hide() ;
 });

});


Tento skript funguje na políčko pro heslo, ale asi již pro vyvojáře nebude problém ho předělat na jakýkoliv input, kde je potřeba vypnout autocomplete.

Záhada s MySQL, kdo ji rozluští?

Nyní jsem strávil asi 3 hodiny hledáním chyby v jádru systému pro eshopy, kdy nakonec oprava (jak už to tak bývá) zabere jen nějakých pár sekund dopsáním jednoho řádku kódu. Takže kde byl problém?

Mějme dotaz do DB:

SELECT `id`
FROM `product`
WHERE (`id` IN (2, 30, 5403, 11640, 11652, 11642, 11653, 12421, 11641, 12404, 12392, 12400, 11654,
12394, 11643, 12405, 9841, 12401, 11656, 12393, 11645, 12407, 11666, 12403, 11655, 12396, 11644,
12406, 12399, 12402, 11657, 12397, 11646, 12398, 11647, 12395, 11650, 11663, 11648, 11664, 11649,
11665, 11651, 12244, 984, 985, 983, 986, 5754, 5753, 3340, 5404, 2781, 1966, 2782, 401, 2806, 1967,
2780, 400, 2807, 3561, 3562, 981, 982, 12667) AND `state` = ‘enabled’ AND `price_vat` > 0)
ORDER BY `php_price_display` DESC, `price_vat` DESC

Jehož výsledkem je (kupodivu):

12244,2,2806,2807,3340,3561,3562,5403,5404,5753,5754,12667,2782,2781,2780,400,401,981,982,983,984,985,986,1966,1967,30,11649,11651,12399,11666,12398,11648,11647,11650,11646,11657,11656,11645,12397,12421,11655,11644,12393,11665,11654,11643,12396,11642,9841,12395,12407,12403,12402,12406,12394,11664,11653,11641,11663,12401,12405,11652,11640,12392,12400,12404,

Ok, na tom asi není nic zvláštního, dobře dále, přidejme k dotazu:

LIMIT 6

a jaký teď dostaneme výsledek??? No přece takový:

12244,2,400,12667,981,982,

Pro ty co nechápou, oč se jedná. Druhý výsledek totiž vůbec nekopíruje výsledek první (od čísla 2 jsou výsledky jinak, než v prvním případě), přitom jsem jen databázi řekl, ať mi z celého výsledku zobrazí jen 6 čísel. Nic víc. No, tuhle chybu v systému nalézt, to byl fakt oříšek. A já blbec prolézal všechny možné napojené moduly, submoduly, porovnával sortovací mechanizmy a nakonec z toho výjde takováhle blbost.

Aby záhada byla kompletní, přídám k dotazu ještě:

OFFSET 12

a jaký je výsledek teď?

12244,2,400,12667,981,982,

ano, vidíte správně. Výsledek je stejný jako dotaz bez OFFSETu. Proto jsme taky na chybu přišli, najednou nám totiž stránkování v systému vyhazovalo stejné výrobky na jiných stránkách.
Ok, teď otázka pro Vás, jakým způsobem tento nešvar MySQL opravíme??? (ne že bych nevěděl, už to opravené mám, jen by mě zajímalo, jak jste si s tím poradili vy)
Omlouvám se zároveň těm, co tohle znají a mají mě za nevzdělaného hňupa – na mou obranu, chybama se člověk učí. Ještě se mi to nikdy nestalo a do budoucna si už na tento nesmysl dám určitě pozor!!!

Přechod webu na SSL

Moje první nasazování SSL jsem rozepsal v mém předchozím článku, nyní, již trošku poučený s chyb, jsem nasazoval SSL certifikát na náš e-shop www.nakupy-detem.cz. Vlastně jsem tento web musel přenést z jednoho serveru na druhý, když už jsem byl u takových změn, tak jsem se rozhodl o větší změnu a zabezpečit tak stránky před “šmejdama” na internetu.

Zásadní otázka: Proč implementovat SSL?

Internet je spojení počítačů ať již kabelem, nebo dnes “bezkabelově” a nikdy nevíte, který “parchant” se dokáže hecknout do Vašeho routeru, nebo na síť spojující Vás a ISP, nebo nedejbože přímo do počítače ISP (Internet Service Provider) přes kterého jste do sítě internet napojeni. Tímto dokáže útočník celkem v pohodě odposlouchávat síť a tím tak získávat data ohledně všech přenosů, které uživatelé na internetu uskuteční. Tak například, chcete snad vědět, jakou pizzu si soused objednává? Není problém, připojte se na jeho router a jelikož jeho oblíbená pizzerie zřejmě nebude mít zabezpečené připojení přes SSL, tak v klidu zjistíte, jakou pizzu si objednal. Ba co víc, díky tomuto spojení není problém mu objednávku změnit a objednat mu na jeho jméno, pod jeho účtem, nějakou pizzu, avšak s dovozem na Vaši adresu.

Jak tomu zamezit? Stačí, aby sousedovic oblíbená pizzerie instalovala na svůj web SSL certifikát a tím by zajistila přenos všech informací šifrovaně. Ano, vy by jste to sice odposlechli, ale místo “heslo: aaa” by se vám objevilo něco jako “lkjls515dafk lkds” – prostě kódováná zpráva, která nejde ničím rozkodovat.

Toto je pouze názorný příklad, banalita s objednáváním pizzy, ale co kdybychom toto udělali s jeho oblíbenou bankou? Tady už je situace jiná. (i když banky již mají šifrované připojení, ale né všechny jsou úplně bezpečné viz. výzkum odborníka na webovou bezpečnost Michala Špačka – Banks & HTTPS in the Czech Republic 2015-03-18)

Na eshopu nakupy-detem.cz zadávají zákazníci (pro někoho) citlivé informace, jako adresu a své jméno, později přibude na webu možnost se zaregistrovat a využívat více možností nákupu výrobků. Tam se samozřejmě budou přihlašovat svým jménem a heslem a pokud by tyto důležité informace nebyly dostatečně zabezpečeny, mohlo by rychle dojit k jejich zcizení a nemalým problémům jak ze strany zákazníka, tak samozřejmě ze straný nás, jako provozovatele obchodu. Zabezpečení stránek certifikátem je tedy jasná a správná volba.

Získání SSL certifikátu a jeho nasazení

Je důležité si nejprve rozmyslet, které domény (subdomény) chci zabezpečit. Pro zabezpečení našeho webu potřebuji ochránit celkem 3 subdomény (nakupy-detem.cz, www.nakupy-detem.cz, a administrační část webu).
K tomu jsem si opatřil certifikát, který je právě pro tři domény. Wildcard by byl taky vhodný, ale zbytečně dražší (navíc implementace je těžší a někdy to nefunguje, jak má, viz. můj minulý článek)
Po získání certifikátu pak stačilo jej poslat kolegům ze server hostingu, aby jej nasadili.

Přechod webu na SSL

U webu jako takového je nutné změnit všechny absolutní vnitřní odkazy, aby směřovaly na HTTPS. Pokud je web, či eshop, postaven na nějakém frameworku, tak většinou stačí jen změnit někde v konfiguraci hlavní url webu (baseUrl), některé frameworky si to i samy detekují a automaticky všechny odkazy k tomu přizpůsobí. Důležité je věnovat pozornost informačním stránkám (vlastně všem místům na stránce, kde se obsah negeneruje, ale je dodáván manuálně, např. wysiwyg editorem v administraci), tam je nutné tyto odkazy buď manuálně změnit, nebo všechny tyto texty prohnat nějakým skriptíkem/filtrem.

Poté je důležité nastavit web tak, aby veškerou komunikaci automaticky směroval na HTTPS. V htaccess souboru se to dělá těmito dvěmi řádky:

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}  [R=301,L]

Problémy s obrázky:

Standardně s obrázky při přechodu webu na SSL nejsou problémy, ovšem na webu nakupy-detem.cz jsem pro optimalizaci kdysi udělal to, že se obrázky stahovaly z různých subdomén (např. img1.nakupy-detem.cz, img12.nakupy-detem.cz0). Tím se standardně obchází maximální počet souběžných připojení prohlížeče na jednu doménu (různé prohlížeče mají různě nastavené omezení, např. Firefox má max 6 souběžných připojení, Internet Explorer verze 10 jich má 8). Problém však nastal, kdy díky certifikátu, který je vystaven pouze na 3 subdomény, toto jaksi přestalo fungovat a prohlížeč odmítal zobrazit obrázky, které přišly z neznámého zdroje. Na subdoméně img2.nakupy-detem.cz vystavený certifikát není, a když se prohlížeč snaží tuto sobdoménu kontaktovat, tak dostane sice certifikát, ale který není ověřený u centrální autority (tzv. self signed) a tím pádem se standardně odmítne ke zdroji připojit. Nyní jsem celkem litoval, že jsem si nezakoupil Wildcard certifikát. Jediný způsob, jak se toho zbavit, bylo odstranění této “subdoménovsko obrázkové” funkčnosti.

Co na to vyhledávače?

Implementováním SSL na web se změnila adresa webu a to na https://www.nakupy-detem.cz. Tohle vyhledávače jako google, či seznam, berou jako úplně novou adresu, avšak díky přesměrování pomocí hlavičky 301 vezmou vyhledávače adresy rychle zpět do svých indexů. Teoreticky by se přechod na tyto nové adresy neměl dotknout pozic ve vyhledávačích, ba co více, google prý hodnotí zabezpečené weby lépe.
Po 12 dnech, co web jede na SSL, jsem v google analytics zaznamenal mírné zvýšení návštěvnosti. Samozřejmě je ještě brzo na nějaké závěry, navíc to může být i jinými okolnostmi. Důležité však je, že žádné snížení návštěvnosti se nekoná.
Jediný problém je pouze v google web masters tools, který okamžitě zaznamenal pokles indexovaných stránek. Je to celkem logické, google bere web s HTTPS jako novou doménu a tudíž už starou neindexuje. Je tedy nutno v toolsech založit nový web s doménou HTTPS. Tam lze již vidět, že to, co verze HTTP ztratila v indexu, to HTTPS nabrala.

Přechod na SSL aneb jakých chyb by jste se dopouštět neměli

Hodně se dnes mluví o bezpečnosti a o zabezpečení zadávaných informací na web, ať již před útočníky v podobě různých hackrů, znuzených studentíků ajťáků, tak i před výzvědnými službami, jako např. ochrana před CIA či NSA. Nedávno, při auditu zabezpečení ve firmě bylo rozhodnuto, že se musí zabezpečit pomocí SSL přístupy na důležité weby v rámci firmy a k tomu i subdomény, na kterých provozujeme demo internetového obchodu. Toto demo se vždy vytváří jako subdoména k demo.firma.cz, tedy například zidle.demo.firma.cz.

Úkol tedy zněl jasně. Zabezpečit firma.cz, ale zároveň i demo.firma.cz ale i např. prodejzidli.demo.firma.cz Jelikož počet subdomén je v tomto případě nekonečný, bylo nutno vytvořit tzv. wildcard certifikát. Pro pořádek jen připomenu druhy certifkátů, které pro zabezpečení webů existují:

standardní SSL certifikát
– je nejlevnější a zajišťuje ověřený certifikát pro jednu doménu, zde nutno připomenout, že doména domena.cz je něco jiného, než www.domena.cz. Pro zabezpečení obou domén je tedy zapotřebí dvou těchto standardních certifikátů

certifikát s podporou SAN

– jsou standardní certifikáty, ale je zde možnost na jeden certifikát mít zabezpečeno více domén (na webech se uvádí až 99, ale myslím, že je to neomezené)

– tento certifikát je pochopitelně o něco dražší i v závislosti na zvolené variantě počtu domén, na které se aplikuje

certifikát wildcard

– speciální druh certifikátu, který zabezpečuje jak doménu samotnou, tak i její subdomény. Doména se v tomto případě do certifikátu vkládá jako např: *.domena.cz

– hodí se na domény, u kterých vzniká mnoho subdomén a přesně nevíme jejich počet

Takže, jak jsem postupoval a jakých chyb jsem se dopustil?

Již nějakou dobu hlavní web firmy běžel na HTTPS pod svým vlatním certifikátem. Já jsem jej však chtěl rozšířit tak, aby fungoval i na ostatní subdomény. Proto jsem úplně na začátku musel vytvořit nový certifikát.

Na internetu je hodně obchodů nabízejících certifikáty, mě se líbily stránky ssls.cz, jelikož mají podporu mnoha certifikátů od pár stovek korun až do několika tisíců. Já si vybrál nějakej wildcard něco kolem tisícovky (ono je celkem jedno jaký, pokud vyloženě nechci mít zelený proužek v adresním řádku prohlížeče, to jsou pak za certifikáty vyšší sumy). Po nákupu je nutno přejít k výrobě takového certifikátu. Stránky jsou celkem přehledné a nabízejí jednoduché vytvoření privátního klíče a CSR žádost, který je potřebný pro žádost o podepsání certifikátu CA autoritou.

Již při vytváření těchto dvou klíčů je nutné zadat doménu, pro kterou se certifikát tvoří. Já tam dal “*.firma.cz”, tím jsem pevně doufal, že tím se certifikát bude používat i pro test.demo.firma.cz. No, ale o tom dále. Po podepsání certifikátu jsem vše zaslal na server hosting, a oni jej přidělili na stránku firma.cz a zároveň pro demo.firma.cz.

Vše tedy běhalo normálně, firma.cz běžela pod https, demo.firma.cz běžela pod https, ale když jsem přešel s prohlížečem na stránku test.demo.firma.cz tak mi vyběhla ta ošklivá stránka upozorňující mě na to, že mě zřejmě chce někdo hacknout a přihlásit mě na stránku, kterou systém nezná (však to znáte, takové to RADĚJI TO HNED ZAVŘI, BO PŘÍJDEŠ O DATA!!!!)

Chyba číslo 1. – nesprávné pochopení wildcard certifikátu:

Aha, a tady je kámen úrazu. Nikde jsem si totiž nepřečetl, že wildcard certifikát funguje pouze na přímé subdomény domény, na kterou je vystaven. Tedy na subdomény subdomény domény již nefunguje. Ono totiž všude se uvádí certifikát jako *.firma.cz a nějak logicky mi přislo, že je jedno kolik subdomén přidám za hvězdičku. Ale opak je pravdou.

No nic, moje chyba, měl jsem si zjistit více informací o tomto. No nevadí, na serveru uvádějí možnost vrácení peněz do 30 dnů, takže jsem je mailem požádal, aby certifikát zrušili a já si tak mohl vytvořit nový, s již správně zadanou doménou.

Chyba číslo 2. – certifikát zrušen bez náhradního:

Zrušení certifikátu proběhlo na mě až nezvykle rychle, což způsobilo, že firemní stránky přestaly fungovat. Je to celkem logické, najednou měly vypovězený certifikát a jiný tam nebyl. Oni totiž administrátoři serveru při zavádění nového certifikátu ten starý zrušili/smazali (což samozřejmě nebyla jejich chyba, prostě se domnívali, že již nebude potřeba). Asi Vám nemusím říkat, co se ve firmě dělo, když vypadla hlavní výloha firmy na webu. Najednou se všichni přiřítili, co se to jako děje, obchoďáci v terénu, co když se teď chlubí webem, co když zrovna teď nějaký zákazník brouzdá na firemním webu. NO PROSTĚ PRŮSER JAK MRAKY. Takže rychle, zavolat na serverhosting, poprosit je, ať tam ihned nahodí starý certifikát.


Chyba číslo 3. – někdy se vyplatí mít zalohované certifikáty na určitém místě:

Čekám, čeká, co tak dlouho na tom serveru dělají? Volám znovu, aha, oni ten starý certifikát hledají – v zálohách pry není. No dobře, jdu za kolegou, který jim před časem certifikát posílal. Kolega hledá v mailech, přeposílá nějaký privátní klíč, posílám webmasterům, čekám. Telefon, “Bohužel, ke klíči potřebujeme také certifikát, bez něho je nám privátní klíč na houby”. Aha, říkám si, vlastně jo. Jdu zase za kolegou, hledá v mailech vydané certifikáty, nějaké mi přeposílá, já posílám na server hosting a zase telefon: “klíče které jste poslal v mailu dříve se neshodují s vydaným certifikátem, který jste poslal nyní !!!!”. Kruci !!!! To už byla tak půlhodinka pryč, co firemní web pořád nejede. No dobře. Je třeba rázného řešení.

Chyba číslo 4. – přílišná horlivost se někdy nevyplácí

Jdu rychle na web pro nákup nového standardního certifikátu. Vybírám takový, u kterého uvádějí, že je automaticky s www i bez www. Ok, beru ho , platím, vytvářím klíče – do políčka pro doménu uvádím: “firma.cz”, vystavuji certifikát. Hmm, ale kde se zadává druhá doména? Tedy doména “www.firma.cz”? Nikde žádné políčko nevidím, asi to bude nějak automaticky…

Posílám webmasterum na hostingu a doufám, že jsem to stihl rychle, než zase někdo příjde, že web stále nejede. Zvoní telefon, na druhém konci zase webmaster: “Certifikát jsme na server instalovali, ovšem tento je určen jen pro doménu firma.cz, www.firma.cz nebude fungovat!!”. KRUCI!!!, Jak to, vždyť tam měli u nákupu napsáno, že bude fungovat i pro www…. No nic, není čas se zabývat drobnostma. Jdu zase rychle na web pro nákup již 3. certifikátu, vybírám stejný standardní certifikát, při vytváření klíčů pro doménu zadávám: www.firma.cz, vystavuji certifikát, posílám webmasterům a již se modlím, aby se web už konečně rozjel.

Blýská se na lepší časy:

Ok, hurá, web se rozjel, nyní již bez problému. Supr, nyní jsem měl konečně trochu času popřemýšlet, proč vlastně ten první (vlastně druhý) certifikát nefungoval pro www.firma.cz? S tímto dotazem se obracím emailem na stránky, kde jsem certifikát objednável. Odpověď přišla záhy, prý se musí do políčka uvést doména ve tvaru s WWW, poté se automaticky vystaví i pro bez WWW. Aha, ale proč to nemají nikde při výrobě certifikátu napsané? Asi proto, aby si lidé koupili certifikáty hned dva!!! No, teď už to vím, tak snad příště už to bude bez problému….

Po těchto zkušenostech musím konstatovat, že přidat šifrování na stránky není zas tak těžké, jen je třeba pamatovat na základní pravidla:

– wildcard certifikat (*.firma.cz) funguje pouze na první subdoménu, na ostatní v řadě již ne !!!!

– při zneplatňování certifikátu je nutné se postarat o to, aby stránky, které tento certifikát mají nainstalovaný, byly schopné provozu i bez něho!!!

– raději si někde bezpečně zalohovat vydané klíče a certifikáty, člověk nikdy neví, kdy je znovu bude potřebovat

– při vytváření standardního certifikátu zadat doménu ve tvaru “www.domena.cz”, automaticky se tak vytvoří certifikát i pro doménu “domena.cz”

– vše dělat pomalu s rozmyslem, při stresu vydá člověk, v mém případě, 2x více peněz za certifikáty, než je třeba

PS: firma.cz či domena.cz nejsou opravdové domény, jsou samozřejmě smyšlené a uvádím je zde jen jako příklad, ale to jste asi pochopili, tak jako by jste tohle PS nikdy nečetli, díky.


Zařízení ipad/iphone a použití :hover

Použití :hover pseudo classy je na dotykovém zařízení celkem pasé, jelikož nedokáži emulovat to, že přes element jen přejíždíme, ale nechceme na něj kliknout.

No jo, ale většina stránek s tímto CSS prvkem počítá a někdy se bez tohoto elementu nedá web ovládat, hlavně u takových,  které mají určité prvky schovány pod najetím kurzoru na určité místo na stránce (např. hover menu).

Apple si to na svých zařízeních vytvořil tak, že hover se snaží emulovat  a to tím, že pro aktivace se provádí kliknutím na element, tím se aktivuje hover efekt a po druhém kliknutí se hover efekt vytratí.

Problém nastává, pokud je hover efekt použit na A HREF elementy. Jelikož zde kliknutím aktivujeme pouze hover efekt, ale stránka zůstává pořád na stejné adrese a nepřesune nás na místo, na které odkazuje HREF. To se provede tzv. dvojklikem, tedy rychlejším dvojkliknutím na daný element.

U jistého projektu mi toto dělalo problém ve vyjíždějícím menu (hover menu). Stávalo se, že na vyjeté menu se na jednotlivé elementy nedá kliknout, a to ani dvojklikem. Nevím přesně, čím to je, snad nějaký hover v CSS, který toto zabraňuje. Nicméně jsem to vyřešil jednoduchým javascriptem:

$('.submenuContent-in a').live('touchend', function (e) {
  e.preventDefault();
  location.href = $(this).attr('href');
});

Nyní mi tlačítka funguji tak, jak mají a na desktop to nemá vliv, jelikož eventa TOUCHEND funguje pouze na dotykových zařízeních.

Více se o tomto problému dočtete třeba zde

Jquery – serializace elementů bez formu

Někdy je třeba serializovat prvky formulářů, které nejsou uvnitř tágu form. Například při vyskakovacím okně, kde všechno probíhá ajaxově a není třeba poutívat form, pouze jeho elementy input, select, atd.

Pokud použijeme příjaz $(element).serialize() na jiném elementu, než na form, dostaneme prázdný string, jak toto obejít?

Na webu jsem chvíli brouzdal a našel jsem toto:
function makeSerializable(elem) {
return $(elem).prop(‘elements’, $(‘*’, elem).addBack().get());
}

var element = $(this).closest(‘tr’);
serialized = makeSerializable(element).serialize();

Funguje bezvadně. Díky ti google vyhledávači….

Kontinuální výstup skriptu ve firefoxu

Každý, kdo pracuje s dlouhotrvájícími skripty ví, že pro lepší kontrolu, co se vlastně v pozadí děje, potřebuje kontinuální výstup. Já si kupříkladu co například 100 cyklů pošlu na výstup počet již zpracovaných položek. Tím si také kontroluji, že se skript nikde neseknul a krásně funguje.

Jelikož PHP používá pro svůj výstup buffer, je nutno pro kontinuální výstup použít funkci:

ob_implicit_flush(true);

Tím je zajištěno, že veškerý výstup skriptu je ihned předán na STDOUT.

U prohlížeče google chrome toto funguje bezvadně, ale pro svůj vývoj mám radši Firefox (má podle mě lepší debugovací nástroj – firebug) – jenže v tomto prohlížeči to nefunguje podle očekávání. Trošku jsem musel googlit a nakonec jsem nalezl způsob, jak přesvědčit firefox, aby ihned zobrazoval to, co mu pošlu. Stačí v kodu specifikovat kodování stránky:

header('Content-Type: text/html; charset=utf-8');