TomasNedela.cz

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.

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.

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í:

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

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….

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');