Nekuřácké kupé - Jakub Bouček » PHP

Čárové kódy na webových stránkách

Jakub Bouček — Wed, 25 Jan 2012 23:11:24 +0000

Čárové kódy známe všichni, jsou to ty podivné čárky a čísly na krabici mléka, sušenkách i kondomech.

Pokud ale vyvíjíte webové aplikace, může se dříve nebo později dostavit požadavek vložit čárový kód i do stránky určené k tisku (například faktura). Samotné vygenerování kódu není takový problém, existují k tomuto účelu desítky různých on-line generátorů i off-line generátorů. Tyto generátory pomocí parametrů v URL vygenerují obrázek, který se klasicky pomocí vloží do stránky.

Samotný problém ale bývá s vložením kódu do stránky tak, aby se zobrazil i na počítači bez internetu (např. při uložení dokumentu na flešku) a aby při tisku nedocházelo k rozostření hran, které jsou způsobeny rozdílem DPI mezi obrazovkou a tiskárnou.

Kvalita tisku

Problém s kvalitou tisku obrázků řešil nedávno na svém blogu i Fakturoid. Řešení je vcelku jednoduché, stačí obrázek vygenerovat třeba ve dvojnásobných rozměrech a ten na stránce stlačit na původní rozměry pomocí .

Prohlížeč potom na obrazovce zobrazí kód takřka stejně jako předtím, ale při tisku, který má mnohem drobnější rozlišení, se takový obrázek vykreslí se všemi detaily, tedy včetně ostrých hran čar.

Příklad můžete vidět na tomto čárovém kódu:

Tento čárový kód je zobrazen na obrazovce v poměru 1:1, ale při tisku je jeho kvalita špatná, pro mnoho čteček nepoužitelná.

Stejný kód generovaný ve větším rozlišení:

Tento čárový kód je zobrazen na obrazovce v poměru 1:4. Při tisku je ale zobrazen prvotřídně.

Pozn.: Některé prohlížeče při tisku nevyhlazují obrázky a proto se mohou oba výše uvedené čárové kódy vytisknout zcela stejně.

Aby kód dobře vypadal dobře na obrazovce, je vhodné striktně dodržovat poměr 1:2 nebo 1:4, protože jinak se bude obrázek přepočítávat přes pixely a bude vypadat ošklivě a rozmazaně (na tisk to má ale minimální vliv).

Nehezký efekt při úpravě velikosti obrázku v jiném poměru než 1:2 či 1:4

Pokud už budete takto násilně upravovat velikost čárového kódu, můžete rovnou generovat obrázek o výšce 1px a velikost pak podle potřeby upravit ve stránce obdobným způsoben. U obrázků čárového kódu bez dalších prvků (např. popisku) lze libovolně měnit poměr obrázku, aniž by to mělo na kvalitu jeho zobrazení vliv.

Tisk bez internetu

Klasické vložení pomocí tagu má několik nedostatků:

Bez připojení k internetu se nic nezobrazí,
Není součástí dokumentu (což například u faktury představuje problém),
Obrázek se generuje při každém zobrazení faktury znovu,
Rozměry obrázku nejsou předem známé, protože ty se definují až při samotném generování podle množství dat.

Všechny uvedené problémy může vyřešit datové URL, tedy obrázek zakódovaný přímo ve zdrojovém kódu stránky. Jeho vytvoření lze v PHP zajistit pomocí funkce base64_encode() a výsledek vypadá následovně:

Čárový kód vykreslený pomocí datového URL

Je třeba ale zvážit, jaké bude primární použití takové faktury. Určitá omezení proto mohou dosáhnout na uživatele, kteří budou mít na svých počítačích starší Internet Explorer. Ten si s datovými URL moc nerozumí. Je proto vhodné toto nasazovat pouze v prostředí, kde lze ovlivnit volbu prohlížeče, například pro účely firemního intranetu. Mimo toto kontrolované prostředí lze datová URL využívat za předpokladu, že čárové kódy na dokumentu jsou pouhým doplňkem a netvoří nezbytnou součást takového dokladu.

PHP – proč si napsat vlastní Framework/CMS/e-shop

Jakub Bouček — Sat, 09 Apr 2011 04:53:05 +0000

Pokud jste četli nadpis jako „Proč si nepsat vlastní…“, pak si jej přečtěte znovu a pozorněji. Opravdu se zabývám tím, pro by si každý programátor měl napsat svůj vlastní Framework, CMS a nebo e-shop.

Jakmile se student programovacího jazyka dostane dostatečně daleko od prvního „Hello world“, přijde první nabídka na vybudování nějakého rozsáhlejšího systému – například e-shopu. Mladý programátor je už otrkaný, ví že stále dokola řeší opakující se problémy a tuší, že by měly vyřešit nějak centrálně – a tehdy poprvé stojí před vnitřním dilematem: Použít hotový a léty prověřený systém, nebo si vytvořit svůj vlastní?

Já tvrdím:
Každý, kdo si někdy položil tuto otázku, by si měl napsat svůj vlastní systém.

Jedině tak na vlastní kůži pozná, co je za tím práce a kolik pastí je třeba překonat – přičichne si k nejhrubšímu meritu problému a otevře si tím svoje oči. Naučí se na věci pohlížet z různých stran, bude lépe předvídat možné budoucí požadavky a rozpoznávat potenciální problémy ještě dříve, než se projeví. Bude o věcech přemýšlet.

Je to jako s auty: Řidič se po své první autonehodě stává mnohem lepším řidičem. Dokud totiž neuslyší mačkání plechů, má tendenci podceňovat nebezpečí, neumí bleskurychle odhadnout, co je důležité (lidský život nad hmotnou škodou) a v krizových situacích má tendence k zbrklým činům. Zvláštní skupinou jsou tzv. sváteční řidiči, kteří v zájmu opatrnosti zásadně nepřekračují rychlost 30 km/h – jejich rčení „za celý život ani škrábnutí“ jsou pověstná.

A tehdy student sám pochopí, že stejně objevuje Ameriku. Jeho systém nedělá nic víc, než mnoho OpenSource projektů – kromě toho, že se mu navíc podařilo obohatit svůj systém o množství chyb, nedostatků, pastí a „až jednou bude čas, tak to dodělám“ věcí. Kromě toho si během prací jeho duše rozdělila systém na části, které má rád a ty, které odbývá v rámci nucených prací, stejně tak znalosti a zkušenosti dokážou plně pokrýt jen některé bloky, jiné naopak fungují někde na pomezí teorie nepravděpodobnosti.

To je ten správný čas připustit si, že svět už má Nette/Wordpress/Magento. Ne dříve ne později. Dříve byste nedokázali vnímat problematiku do hloubky a naopak později by se vám mohlo stát, že vám váš vlastní systém vezme svobodu a budete zajati molochem, který už nemůžete hodit přes palubu, protože by vás stáhl s sebou.

Zkuste o tom přemýšlet.

Subdomény a komerční hostingy

Jakub Bouček — Thu, 16 Apr 2009 00:42:30 +0000

Pokud vlastníte doménu (doménové jméno), jistě víte, že můžete využívat i tzv. subdomény (či poddomény), tedy dalších jmen, které rozšiřují původní doménové jméno. Například, pokud vlastníme doménu koldasoft.cz, můžeme zcela volně využívat odvozených domén jako třeba www.koldasoft.cz, či reference.koldasoft.cz a nebo cerberus.koldasoft.cz. Možnosti využití jsou široké. Více o doménové problematice najdete na Wikipedii.

V tomto článku bych se rád zamyslel nad realizací hostingu pro takovéto subdomény na webovém serveru. Zejména jejich správu a rozložení v souborové struktuře z pohledu správce webu.

U drtivé většiny hostingů se provádí nahrávání stránek na server hostingu pomocí FTP nebo jiné podobné technologie (SCP, SVN-put, atd.). Po přihlášení server klientovi zpřístupní adresář serveru, ze kterého webový server bude načítat stránky. Zde však již mezi poskytovateli hostingu vzniká základní rozdíly:

Některé hostingy zobrazují obsah na webu obsah rootu FTP. Dělají to najčastěji amatérské servery typu one-man-show s minimálními zkušenostmi. Ze zkušenosti takový hosting považuji za méně kvalitní a podpory bývá nepřístupná individuálním požadavkům. Takový server často používá nestandardní nastavení.
Někde se stránky musí nahrát do adresáře public_html. Toto se vyskytuje zřídka, především u velkých podniků, které hostingové služby mají jako okrajovou činnost a menší společnosti většinou s mizernou podporou. Toto je defaultní nastavení distribuce serveru a vykazuje tak snahu zprovoznit hosting co nejrychleji a s minimálními náklady - servery jsou nedotažené, ovládání těžkopádné. Takový hosting s velikou pravděpodobností nebude schopen a ochoten naslouchat Vašim individuálním požadavkům, protože je nastaven na velmi prostý automatický systém, který neumožňuje velké zásahy.
Jinde se po přihlášení do FTP zobrazí několik různých adresářů, z nichž právě jeden je určen obsah webu. Taková konfigurace je většinou propracovaná a umožňuje široké možnosti nastavení serveru na míru. Tuto konfiguraci používají vyspělé hostingové společnosti.
Adresáře přístupné přes FTP mívají pak různé významy. Jeden z nich představuje adresář s daty webové aplikace, druhý umožňuje nahrávat soukromé soubory, které nebudou z webové aplikace přímo přístupné (zabezpečení) a další mohou obsahovat například logy, nebo jiné konfigurační nástroje.

Subdomény

Výrazně složitější situace je v případě řízení subdomén. I zde se přístup hostingů rozděluje na několik základních typů:

Snad nejhorší řešení, které jsem kdy viděl, má webhosting na Forpsi. Na serveru poddomény nejsou vůbec řešeny, pouze při přístupu na libovolnou poddoménu je volán určitý PHP skript, který sám musí rozlišit, o jakou poddoménu jde a volat tak nějaký podskript. Otřesné.
PHP script pro zpracování domény. Zdroj: kb.forpsi.com
Nastavení domény administrátorem na žádost. Je to sice krkolomné, ale na nízkorozpočtových a nebo velmi individuálních serverech je to velmi časté řešení. Pokud je správce vstřícný a rozumný, v praktickém provozu může být tato varianta zcela uspokojivá.
Dalším nevhodným způsobem vytváření sudomén je, když jakýkoliv podadresář v adresáři s obsahem webu se automaticky stává subdoménou. Na takových serverech není možné provozovat jakoukoliv aplikaci, která pracuje s citlivějšími daty – pokud nejsou jen v databázi. Jde o to, že takový hosting jen brání vytvoření přehledné souborové a adresářové struktury. Jednak proto, že adresáře poddomén překáží a za druhé, že obsah umístěný v adresáři je přístupný i přes subdoménu. Navíc jsou pak velmi obtížně použitelné nástroje, jako je SVN a pod.
Toto řešení je překvapivě často používané na serverech, což nechápu, protože je považuju v praxi za nepoužitelné.
Poněkud lepší řešení je ukládání do adresáře „subdomains“, který je ovšem opět umístěn v adresáři s obsahem webu. Většina nevýhod uvedených v předchozím bodu odpadá. Přesto pro profesionální nasazení není ani takovýto systém rozhodně vhodný.
Jediný opravdu praktický a plnohodnotně využitelný způsob souborovým řízení poddomén je jejich umístění na stejnou úroveň.
Strukura FTP

Na obrázku je jedna z nejlepších struktur adresářů na běžném hostingu. Soubory pro hlavní doménu jsou v adresáři /web/www/ a další poddomény jsou v adresářích na stejné úrovni, tedy /web/subdomena/, ap. I když to může znít komplikovaně, ve skutečnosti je to velmi příjemné řešení.
Toto řešení používají opravdoví profesinálové, na českém poli zejména: Tojeono.cz, Ebola.cz, Ceskyhosting.cz a dokonce i Pipni.cz.

Vyzývám tímto všechny hostingové společnosti, aby si tato slova szaly k srdci a trochu se zamysleli dříve, než vpustí klienty na své servery.

PHP: magická funkce __toString() nemůže vyhazovat výjimky

Jakub Bouček — Wed, 15 Apr 2009 22:19:32 +0000

Věděli jste to?

Bohužel o tomto faktu dokumentace dosti nepříjemně mlčí a tak jsem jednoho dne narazil.

Problém s přílohami ve SquirrelMail 1.4.13

Jakub Bouček — Sat, 14 Jun 2008 23:20:42 +0000

V týdnu jsem dostal hlášení od Koldy, že jednomu z našich klientů nejdou odesílat přílohy. Pozastavil jsem se nad podivností této chyby a odkazoval jsem ho na nastavení jeho e-mailového klienta – myslel jsem totiž, že se k serveru připojuje pomocí POP3 a SMTP serveru, jako drtivá většina našich klientů. Jednalo se však o chybu na našem webovém rozhraní SquirrelMailu, které bylo klientům poskytnuto jako alternativa a po několik měsíců nebylo nikým využíváno.

Google, ani letmý pohled do dostupné dokumentace mi nenapověděl.

Při pokusu o uložení se vracela chyba Nelze přesunout/zkopírovat soubor. Soubor není přiložen (v originále Could not move/copy file. File not attached).

Prošel jsem celou konfiguraci, zkontroloval všechna nastavení, ale vše se zdálo být v pořádku. Teprve až podrobným zkoumáním kódu, který zpracovává soubory tvořící přílohy mailu jsem vyvolal podrobné chybové hlášení PHP:

Warning:  move_uploaded_file(../attach/DynUVxB1G8peSN2zHNJWLs7s2lXvJN5K) [function.move-uploaded-file]: failed to open stream: No such file or directory in /web/webxyz.cz/mail/src/compose.php on line 1389
Warning:  move_uploaded_file() [function.move-uploaded-file]: Unable to move '/web/_temp/upload/phpAA80.tmp' to '../attach/DynUVxB1G8peSN2zHNJWLs7s2lXvJN5K' in /web/webxyz.cz/mail/src/compose.php on line 1389

A byl problém na světě. Ve standardní distribuci nejsou připraveny některé adresáře nezbytné pro plnou funkčnost projektu a je třeba je ručně vytvořit. Konkrétně adresář /attach v rootu projektu.

Jak jsem si zaškodil

Jakub Bouček — Tue, 30 Oct 2007 03:08:00 +0000

Mým klientům a partnerům umožňuji využívat některé služby poskytované z mého účtu na hostingu. Jednou z takových služeb je umístění některých doplňků stránek (videa, fotky, ap.) na rychlejší hosting, než je zbytek webu. Velikou výhodu spatřuji v tom, že tyto služby mohu monitorovat a spravovat jednotně.Příkladem takové slžby je třeba vložené video do prezentace Plzeňských ohýnků.Po delší době jsem se zašel podívat na statistiky návštěvnosti a nestačil jsem se divit. Služby byly neúměrně zneužívané více erotickými weby.

V první chvíli jsem zcela nechápal, jak je možné, že za poslední dva měsíce bylo staženo přes 3 GB dat, zatímco běžně se přenos pohyboval v řádů desítek MB.

Až pohled níž, do seznamu stránek, které služby využívají, mi podal vysvětlující informace. Doslova stovky adres, které sprostě zneužívaly v několika posledních měsících mnou poskytované služby k účelům, se kterými nesouhlasím – dokonce jsou přímo v rozporu s podmínkami hostingu, na němž služby provozuji (v ilustraci níže jsou nežádoucí adresy označeny červeně).

Abych byl upřímný, před časem jsem s pardubickou rádoby erotickou agenturou spolupracoval na internetových projektech a v rámci spolupráce jsem umožnil použití mnou spravovaného přehrávače video-sekvencí. Již tehdy jsem zdůrazňoval, že si výslovně nepřeji, aby byl nasazován pro jiné použití, než jak jsem jej tehdy nastavil a zprovoznil. Přehrávač byl tehdy použit pro uvítací, erotiky zcela prostou, nahrávku.

Krátce po té jsem ukončil s agenturou spolupráci – o důvodech bych se zde nerad blíže zmiňoval. Náhodou jsem sice zaznamenal, že se přehrávač objevil i na sousedních stránkách agentury, přestože tam neměl co dělat, ale blíže jsem se tím nezabýval.

Jenomže přehrávač, jak jsem dnes zjistil, byl použitý na mnoha stránkách věnovaných erotice a byly skrz něj přehrávány pornografické záběry.

Jak se zbavit pijavice

Přemýšlel jsem, jak problém efektivně odstranit.

První nejjednodušší variantou bylo prosté smazání přehrávače z místa, odkud je stahován. Tím bych však poškodil asi desítku klientů a další desítky soukromých projektů – včetně tohoto blogu – bych citelně ochromil. Musel bych pak ručně obejít všechny stránky, kde je přehrávač umístěn a opravit je.

Další nevýhody tohoto řešení:

Uživatelé by byli zmateni a nedostatečně informováni,
poškodil bych své slušné klienty, kteří za nic nemohou,
viníci by nebyli dostatečně potrestáni,
snadno by se mohl problém opakovat
a hlavně, to prostě nebylo dost cool!

Vzpomněl jsem si, jak podobný problém řeší server blog.cz. Pokud je jejich obrázek vložen do cizí stránky, nezobrazí se. Namísto toho se však zobrazí nápis, že tohle se prostě nesmí.

V mém případě jsem však neměl situaci tak jednoduchou. Jediné, čím jsem mohl manipulovat byl přehrávač – flashová aplikace, která se stahovala z mých stránek. Nemohl jsem však již ovlivnit jeho nastavení, které bylo vepsáno přímo ve stránce, ke které jsem neměl přístup. Také jsem nemohl ovlivnit přehrávaná videa, protože tato jsou stahována z jiných serverů.

Neumím ani pracovat s Flashem, takže podvrhnout přehrávač nepřipadalo v úvahu.

Začal jsem tedy zkoumat způsob vložení přehrávače do stránky a hledal jsem, zda by se v některém místě nedala najít slabina, kterou mohu využít. Byla tam. Vzhledem k tomu, že, přehrávač je získáván protokolem HTTP z adresy //fotky.boucek.info/player/flvplayer.swf, lze přikázat prohlížeči, aby se přesměroval na jinou adresu.

Všiml jsem si, že existují dvě metody, jak v HTML definovat parametry, ze kterých přehrávač čte cestu k přehrávanému videu:

<embed src="http://fotky.boucek.info/player/flvplayer.swf?file=http://cesta/k/videu.flv"

width="320" height="260"

type="application/x-shockwave-flash" />

a nebo:

<embed src="http://fotky.boucek.info/player/flvplayer.swf"

width="320" height="260"

type="application/x-shockwave-flash"

flashvars="file=http://cesta/k/videu.flv" />

Bohužel všechny kradené prohlížeče jsou do stránek vkládány pomocí druhé varianty, tedy pomocí atributu flashvars. To je problém, protože pomocí přesměrování lze ovlivnit pouze parametry předané přímo v adrese přehrávače.

V zoufalství jsem zkusil ještě zkombinovat obě varianty a do kódu umístit cestu k videu oběma metodama a sledovat, která bude mít větší prioritu. Přehrávač totiž může pochopitelně v jednom okamžiku přehrávat pouze jedno video, proto si musí vybrat jedno z nich.

Naštěstí přehrávač dává přednost parametrům uvedeným přímo v adrese přehrávače, takže vhodným přesměrováním lze snadno změnit chování přehrávače.

Tím byla odstraněna poslední překážka a mohl jsem začít škodit :-)

Jdeme škodit

Ujasnil jsem si body, které musí akce splňovat:

Musí zasáhnout pouze nežádoucí kopie přehrávače,
ostatní musí zůstat bez změny funkce,
musí být funkční ve všech prohlížečích,
přesměrování musí jít ovlivňovat velmi rychle, být flexibilní – to pro případ, že by změna přeci jen zasáhla přehrávače na stránkách klientů.

Před začátkem programování jsem si připravil video, které budu prohlížeči podstrkovat. Volil jsem ostré viditelné a kontrastní barvy – červenou a bílou. Na konci videa jsem si neodpustil emotivní vyštěknutí :-)

Časově nejnáročnějším úkolem bylo naprogramování kódu, který bude dělat přesně to, co se po něm chce.

Sepsal jsem klíčová slova, kterými jsem odlišoval žádoucí a nežádoucí kopie. Tato slova se mohla vyskytovat v adrese, kterou byl přehrávač volán, nebo v adrese stránky, do které byl stahován (tzv. referer). Klíčová slova jsou tato:

papaya-agency.com,
q3.cz,
ceskeholky.cz,
sex,
erotic,
porno.

Dále bylo třeba zajistit, aby nedocházelo k nekonečnému přesměrovávání. To by se mohlo stát, protože když si prohlížeč zavolá přehrávač, dostane příkaz, aby se přesměroval na novou adresu. Prohlížeč musí poslechnout, tak volá přehrávač z nové adresy. Jenže obě adresy jsou skoro stejné, jen ta druhá je doplněná o cestu k nastrčenému videu, tudíž by prohlížeč dostával stále příkaz k přesměrování. Proto jsem nastrčenému videu dal neobvyklý název: „robber.fvl“ [zloděj, lupič] a zajistil, že pokud se volá přehrávač, který v adrese obsahuje slovo „robber“, nebude dále přesměrovávat.

Jak takové přesměrování praktikovat na serveru? Protože server soubor s příponou *.flv nijak nezpracovává, ale pouze posílá, je třeba pomocí Rewrite, nebo jiné funkce serveru přepsat volanou adresu na nějaký PHP soubor. K tomu postačuje řádek ve tvaru: RewriteRule ^.+$ index.php [L].

O zbytek už se postará PHP:












//Get base name of GET address




$uri_orig





=





$_SERVER





[





"REQUEST_URI"





];




$uri_bases





= array();




preg_match





(





'/^[^?]*/'



,





$uri_orig



,





$uri_bases





);




$uri_base





=





basename





(





$uri_bases





[





0





]);




//Verify base path and fix it to default if need




if (!





file_exists





(





"./$uri_base"





) ||





preg_match





(





'/\.php$/'



,





$uri_orig





))




$uri_base





=





"flvplayer.swf"





;



//Get referer URL




$uri_ref





=





""





;

if (isset(





$_SERVER





[





'HTTP_REFERER'





]))




$uri_ref





=





$_SERVER





[





'HTTP_REFERER'





];




//Set block_it flag to default




$block_it





=





false





;




//Find referer in blacklist




$uri_ref_blacklist





= array(





'/papaya-agency\.com/'



,





'/q3\.cz/'



,





'/ceskeholky\.cz/'



,





'/sex/'



,





'/erotic/'



,





'/porno/'





);

foreach(





$uri_ref_blacklist





as





$uri_ref_bad





)




$block_it





=





$block_it





||





preg_match





(





$uri_ref_bad



,





$uri_ref





) ||





preg_match





(





$uri_ref_bad



,





$uri_orig





);




//Disable if already fixed




$block_it





=





$block_it





&& (!





preg_match





(





'/robber/'



,





$uri_orig





));




//Pokud se má blokovat




if(





$block_it





) {




//...blokuj




header





(





"HTTP/1.1 307 Temporary Redirect"





);




header





(





"Location: http://fotky.boucek.info/player/$uri_base?image=http://fotky.boucek.info/robber.gif&file=http://fotky.boucek.info/robber.flv"





);

} else {




//...když ne, tak pošli původní soubor, kterej byl žádanej




if (





preg_match





(





'/\.swf$/'



,





$uri_base





))




header





(





'Content-Type: application/x-shockwave-flash'





);




header





(





'Content-Length: '



.





filesize





(





"./$uri_base"





));




readfile





(





"./$uri_base"





);

}



?>

A stránky jsou rázem ozdobené: