Myšlenky dne otce Fura

Templatovací jazyky v Javě mají poměrně dlouhou minulost. První a zřejmě nejznámnější jsou JSP, které jsou součástí javy. Jsou nejstarší z rodiny templatovacích jazyků a přestože jsou masivně používány dodnes, mnoho lidí k nim má své výhrady:

• psaní JSP je obtížné pro ne-java programátory - přestože původní myšlenkou bylo, aby JSP psali odborníci na web (tedy “webdevelopeři”) tato myšlenka zcela jistě minula realitu; praxe je taková, že JSP píší z různých důvodu opět Java developři, jejichž je jednak nedostatek a jednak jejich zaměření je spíš na aplikační kód než na validitu a použitelnost HTML výstupu
• JSP stránky nejsou použitelné, díky životnímu cyklu JSP (JSP -> .java -> .class), mimo servletový kontejner - to znamená, že teprve servletový kontejner po nadeployování web aplikce JSP převede na implementace Servletů a přeloží je do binární podoby. Dopady tohoto mechanismu jsou poměrně jasné
  • JSP stránky mají své pevné umístění - hledají se vždy na filesystemu v adresáři web aplikace; nelze je umístit na classpath (a učinit je tak součástí přenositelných knihoven), nelze je načítat z jiného zdroje - např. databáze (a umožnit tak vznik nových stránek za běhu na systémech, kde nemáme přístup na filesystém), nelze definovat jakoukoliv složitější logiku načítání stránek krom dodání Erorr 404 stránky (např. custom logika ve smyslu neexistuje-li primární šablona, použij záložní, neexistuje-li ani ta, zobraz chybu)
  • JSP stránky není možné jednoduše testovat - jejich výstup získáme teprve až dotazem na servletový kontejner
  • JSP nelze použít pro skládání jiného výstupu než do web browseru - např. pro skládání těl emailů musíme volit jiný templatovací engine
  • debugování JSP nebylo poměrně dlouho možné a ani dnes to není zcela samozřejmá a jednoduchá věc (co se setupu týče)
  • chybové hlášky JSP stránek jsou při určitém (často standardním) nastavení kontejnerů nečitelné (vztahují se k vygenerovaným servletům a nikoliv k původní template) - změna tohoto nastavení typicky vyžaduje stop/start kontejneru
• JSP stránky díky možnosti psaní scriptletů vybízejí k míchání aplikační logiky do prezentační vrstvy - s tím se myslím setkal každý z nás a leckdo se k tomu někdy i uchýlil
• v případech některých kontejnerů je při změně JSP a požadavku na její opětovné vyrenderování znatelná časová prodleva - kompilace JSP vyžaduje nějaký čas (možná se jedná jen o zlomky vteřiny, maximálně vteřiny, ale při ladění nějakých drobnostní na stránce se jakákoliv prodleva počítá)

Reakcí na zmíněné nevýhody byl vznik interpretovaných templatovacích jazyků. V tomto příspěvku bych se chtěl podívat na zoubek dvěma nejznámnějším - Apache Velocity a FreeMarkeru.

(pokračování …)

V odkazech na sledované blogy se mi objevil Blog v pavučině, který píše můj kolega z web designerského oddělení Forrestu. Blog je zaměřen na JavaScript a webdesign, což je oblast, kterou možná jako Javisti orientovaní na web nemáme úplně rádi, ale je pro naši práci nezbytně potřeba (i když s nástupem jQuery se můj pohled na JavaScript radikálně změnil ). Vypíchnu jen pár jeho článků a názor si udělejte sami:

• Seriál o regulárních výrazech v JavaScriptu - vyšlo také na www.interval.cz
• Loading… animace na pár kliknutí - rozřešení záhady, kde se neustále berou nové verze “loading” animací
• jQuery: AJAX load a cache - IE a cache, kapitola sama pro sebe
• Textarea de Luxe - luxusní TextArey pro editaci zdrojového kódu
• Alternativní scrollIntoView() pro IE
• Rozlišení CSS stylů pro různé verze Internet Exploreru

Přeji příjemné čtení.

V tomto příspěvku se nechci věnovat popisu zprovoznění jCaptchy v bezpečnostní frameworku Acegi Security, jelikož toto je velmi dobře popsáno již v existujícím článku na MoroSystems weblogu. Spíš se chci zaobírat způsobem, jakým se k integraci do Acegi frameworku autoři postavili. Tento způsob mi přijde totiž přinejmenším neobvyklý. Zachovává sice zavedené principy Acegi, ale ten neodpovídá mým (ale řekl bych vcelku přirozeným) představám o tom, jak by měla captcha ve web strákách fungovat.

Princip práce s captchou v Acegi je podobný principu standardního přihlašování. Acegi při přístupu na “chráněné url” kontroluje ověření uživatele v SecurityContextu a pokud uživatel není ověřen, přesměruje tok aplikace na přihlašovací formulář nebo v případě captchy na formulář obsahující obrázek a textové pole pro vepsání rozpoznané captchy. Pokud řešíme přihlašování, je tento způsob přirozený - v případě captchy však očekávám, že captcha bude rovnou součástí formuláře, který je “hlídán”. Tak ale integrace jCaptchy v Acegi ve svém základu nefunguje.

Pokud Vám tento způsob připadne taky trochu podivný a zajímá Vás, jak si s tím poradit, čtěte dál.

(pokračování …)

Though most of articles at this blog are written in my native language - Czech, this one will be different. I have chosen an English to address wider community of Stripes developers - I think there would’nt be enough readers in our beautiful small country. So, please, excuse possible errors and mistakes in the article, I will try my best .

Common introduction to AJAX in Stripes

Stripes framework offers basic but sufficient support for AJAX that is covered with article at official web site. Article recommends using commonly known PrototypeJS AJAX client side library. On the server side, request is processed by Stripes themselves by standard population and execution as any other http request (that means that data from client to server are sent as a standard URL encoded parameters). What you get is correctly populated and validated action bean - and until now you haven’t even recognize, that request is made by JavaScript on the client side not even you have to care of it. You can access session, exchange cookies and so on.

(pokračování …)

Kamarád mi poslal odkaz na zajímavý článek. Jistě všichni znáte ochranu zneužití veřejně dostupných formulářů pomocí CAPTCHA. Koneckonců je většina z nás má na svých blozích po tom, co nám začaly chodit spamové komentáře k článkům. Pánové z Carnegie Mellon University však našli způsob, jak tento otravný fenomén převést na něco, co je užitečné.

(pokračování …)

Jsou chyby malé, velké, závažné i triviální, úsměvné, spletité i velmi hloupé. Z celého pokolení chyb je tahle velmi, velmi stará a také dost hloupá. A vypadá to, že z úcty k jejímu věku, ji nechá M$ už pokojně dožít spolu s chatrčí zvanou Internet Explorer.

Na chybu narazíte tehdy, když coby Java programátor napíšete servlet, který vrací binární data přes protokol HTTPS (např. vygenerovaný MS Excel jako já, nebo třeba PDF atd.). Aniž byste to explicitně nastavili do HttpResponse, bude vrácená odpověď (pravděpodobně) obsahovat v hlavičce tyto údaje:

O to se vám postará váš web server (v mém případě Tomcat i Apache zároveň). Internet Explorer se však k vrácené binární odpovědi s těmito hlavičkami obrátí zády a lakonicky vás informuje: “Aplikace Internet Explorer nemůže otevřít tento server v síti Internet. Požadovaný server není k dispozici nebo jej nelze najít. Akci zopakujte později.”

Tato chybka je dle některých zdrojů v Exploreru už od verze 4.0 (byť záznam v knowledge base Microsoftu tvrdí, je reportovaná až u IE 6.0 SP1) a přetrvává až do současné verze 7.0, což jsem si měl bohužel možnost vyzkoušet na vlastní kůži.

(pokračování …)

Nedávno na jednom připomínkovacím sezení mě zákazník překvapil přáním, že bych chtěl chránit své emailové adresy uvedené v kontaktech jako <a href=”mailto:blabla@blabla.cz”/> proti zneužití spamboty. Jedná se o poměrně jednoduché přání, se kterým jsem se ale ve své praxi setkal poprvé. Obvykle, většina z nás akceptuje toto riziko výměnou za to, že naši zákazníci jednoduše kliknou na odkaz a otevře se jim rovnou jejich mailový klient s předvyplněnou adresou. Ihned nás napadlo vyměnit mailto linky za emaily vepsané např. do obrázku, ale to bychom přišli o tu výhodu jednoduchého otevření mailového klienta s adresou. Nicméně jednání jsme ukončili s vědomím, že si klient bude muset vybrat jedno nebo druhé. Nakonec mi to ale stejně nedalo a zkusil jsem pana gůgla …

(pokračování …)

Je možné zajistit bezpečné sdílení HTTP session mezi oběma protokoly? Z dostupné dokumentace se dozvídáme, že nikoliv. Tento článek se zabývá možným řešením, které za jistých podmínek umožňuje bezpečně sdílet společnou session. Důvod proč se tímto problémem zabývat je jednoduchý - SSL šifrování je výpočetně nákladná věc (viz. např. Performance analysis of Secure HTTP Protocol). Proto je možná vhodné používat HTTPS pouze tam, kde je k tomu důvod (tedy např. uživatel pracuje s některými důvěrnými daty). Jistě se shodneme na tom, že na řadě webových aplikací je takto důvěrných míst pouze pár a zbytek bychom mohli hnát klidně přes protokol HTTP, čímž odlehčíme svému webovému serveru. Jenže tady narážíme na zásadní problém - nemůžeme nechráněným protokolem vyzradit identifikátor session (a naopak nesmíme akceptovat session, která vznikla přes protokol HTTP). Má tedy tato situace řešení, nebo nemá, jak se dočteme v řadě publikací?

Kolega Martin Veska ze společnosti FG Forrest přišel s návrhem řešení, které by umožňovalo bezpečně “vyzradit” identifikátor session, aniž bychom se vystavili riziku záměny autorizovaného uživatele. Jako každé jiné řešení má i toto své mínus, ale o tom až později v článku.

Odesláno k Bezpečnost, Java, Web | Zatím bez komentářů - buďte první! »