Filtry v Tomcatu

17.12.2007 11:21 | Přečteno: 1635× | | poslední úprava: 18.12.2007 08:59

Lehký úvod do filtrů (v Tomcatu).

Před časem jsem si trochu hrál s filtry v Tomcatu a rozhod jsem se s vámi podělit o některé elementární poznatky, které jsem při tomto hraní si nabyl. V Javě jsem cca 97% začátečník. Toto krátké shrnutí je tedy pro 98 a 99% začátečníky. Experti na Javu zde asi nic nového nenajdou (maximálně mě můžete upozornit na to, zda jsem něco napsal mylně či zavádějícím způsobem).

Java servlet specifikace od verze 2.3 obsahuje filtry. Filtry jsou komponenty určené k dynamické transformaci requestu/responce nebo k získání informací z nich. Příchozí request prvně projde filtrem, poté je zpracován v JSP/servletem, vygenerována response a ta opět může projí filtrem, jak je znázorněno na obrázku.

Díky filtrům můžeme snadno vytvářet znovupoužitelná řešení často se opakujících úkolů. Ve filtru můžeme také modifikovat jak request tak response. Časté využití filtrů tak spočívá v

• autorizaci přístupů na dané stránky (k tomu pochopitelně můžeme použít i jiné metody, např. JDBC realm), logování přístupů,
• přesměrování requestu (na základě autorizace nebo na lokalizované stránky anebo za účelem hezkého vzhledu adresy - např. změna /cestopisy/norsko na category=cestopisy&country=norsko )
• ... a spoustě dalších.

Každý filtr musí implementovat rozhraní javax.servlet.Filter, tj. implementovat metody init(FilterConfig filterConfig), destroy() a doFilter(ServletRequest request, ServletResponse response, FilterChain chain). V metodě init(FilterConfig filterConfig) provádíme inicializaci filtru. Zde je např. možné načíst počáteční hodnoty parametrů ze souboru web.xml (tag <init-param>). Metoda destroy() je volána kontejnerem při ukončování filtru. Většina věcí se obvykle odehrává v metodě doFilter(ServletRequest request, ServletResponse response, FilterChain chain).Tato metoda je volána při každém novém requestu/response. Parametry request a response jsou vcelku jasné, z requestu můžeme o požadavku vytáhnout vše, co nás zajímá a provést nějakou logiku nebo např. na základě těchto informací změnit response. Parametr filterChain obsahuje informace o tom, jaké filtry se mají vykonat a v jakém pořadí. Poté, co provedeme vše, co jsme chtěli, zavoláme chain.doFilter(request, response), což způsobí zavolání následujícího filtru. V případě, že je to poslední filtr, předá se request servletu/JSP. Poté je response opět předána filtru. Pokud tedy chceme nějakým způsobem modifikovat obsah response ze servletu, kód, který ji bude modifikovat, bude až za chain.doFilter(request, response). Pokud budete chtít response modifikovat (tj. aby servlet poslal response filtru a ne přímo klientovi), je potřeba předávat ne samotný response, ale nějaký obalující objekt (např. HttpServletResponseWrapper).

Podívejme se na jednoduchý příklad. Mějme např. v session uložený atribut isUserInAdminRole, který bude nastaven na true v případě, že uživatel je přihlášeny a má práva administrátora. V metodách init a destroy tedy nepotřebujeme provádět nic. V metode doFilter načteme ze session tento atribut. Pokud bude mít hodnotu false, přesměrujeme odpověď na stránku accessDenied.html, pokud bude mít hodnotu null, tak uživatel není přihlášený a provedeme tedy přesměrování na stránku login.html. Celý filter by mohl vypadat nějak takto:

public class AdminFilter implements Filter{
privateFilterConfig filterConfig = null;
public void init(FilterConfig filterConfig){
   this.filterConfig = filterConfig;
}
public void destroy(){
   this.filterConfig = null;
}
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException{
  HttpSession session = ((HttpServletRequest)request).getSession();
  Boolean isAdmin = (Boolean)session.getAttribute("isUserInAdminRole");
  if(isAdmin == null){
     ((HttpServletResponse)response).sendRedirect("login.html");
  }
  else if(isAdmin.booleanValue()){
     chain.doFilter(request, response);
  }
  else{
     ((HttpServletResponse)response).sendRedirect("accessDenied.html");
  }
}
}


O tom, že se má filtr použít dáme Tomcatu vědět tak, že změníme soubor web.xml. Zde bychom rovněž uvedli počáteční hodnoty parametrů, které bychom mohli načíst v metodě init. Filtry se pak vykonávají ve stejném pořadí, v jakém jsou uvedeny ve web.xml. V našem jednoduchém příkladě ale jediné, co potřebujeme, je sdělit Tomcatu, jaká třída filtr implementuje (AdminFilter) a na jaké adresy se filtr má použít (cokoli začínající adresaAplikace/admins/). Část web.xml by mohla vypadat takto:

<filter>
   <filter-name>Is Admin Filter</filter-name>
   <filter-class>AdminFilter</filter-class>
</filter>
<filter-mapping>
   <filter-name>Is Admin Filter</filter-name>
   <url-pattern>/admins/*</url-pattern>
</filter-mapping>


Možnosti filtrů jsou pochopitelně širší, toto byl jen pokus o stručný úvod. O něco více podrobné informace najdete např. na stránkách uvedených níže.

Zdroje

V angličtině:
The Essentials of Filters na stránkách Sunu,
Filtering tricks for your Tomcat na stránkách IMB.
V češtině:
pěkný seriál na interval.cz,
a jeden kratší článek na linuxzone.eu.

       

Komentáře

[Filip Jirsák]

V Javě jsem cca 97%-ní začátečník.

V češtině asi taky, ne? „97%“ (bez mezery) znamená „devadesátisedmiprocentní“ (97 % s mezerou by pak znamenalo „devadesát sedm procent“). Podobně třeba „5 km“ je „pět kilometrů“, „5km“ je pětikilometrový. Takže „97%-ní“ znamená „devadesátisedmiprocentní-ní“, což jak jistě uznáte, moc smysl nedává.

U mapování filtrů je potřeba dát pozor na to, že filtry je možné namapovat k cestě (URL) nebo k pojmenovanému servletu. Jakmile má servlet přiřazený nějaký filtr podle jména, žádný filtr mapovaný podle URL se na něj neaplikuje.

Taky je potřeba dávat pozor na to, že jakmile kdokoli (filter nebo servlet) prvně přečte jakýkoli parametr z požadavku (nebo vlastní tělo požadavku), „zakonzervuje“ se nastavené kódování požadavku a následné volání request.setCharacterEncoding(String) už nemá žádný vliv. Což vám klidně může udělat nějaký filtr, který si chce třeba jenom přečíst, zda v požadavku náhodou není parametr debug, aby vypsal nějaké ladicí informace. Takže bývá dobré jako první filtr použít filtr, který zavolá request.setCharacterEncoding(String) (nejspíš s nějakou konstantou, protože si nedovedu představit, k čemu by bylo dobré měnit kódování stránek na jednom webu).

[Daniel Kvasnička ml.]

Taky je potřeba dávat pozor na to, že jakmile kdokoli (filter nebo servlet) prvně přečte jakýkoli parametr z požadavku (nebo vlastní tělo požadavku), „zakonzervuje“ se nastavené kódování požadavku a následné volání request.setCharacterEncoding(String) už nemá žádný vliv.

Nejen u requestu, u response je to podobne. Nedavno jsem v jednom svem servletu zarizoval, aby se na TransformerException (jejimz zdrojem byla FileNotFoundException) poslala chyba SC_NOT_FOUND a Tomcat vlitnul na mnou definovanou chybovou stranku. A dokud jsem nezaridil, aby se Writer z response ziskaval az po transformaci (a tedy po potencialni vyjimce saxonu), vzdycky byla chybova stranka poslana s "rozsypanym cajem"...

[dementni.lojzik]

Diky za komentare.
Ano, co se tyce cestiny, jsou me (ne)znalosti priblizne stejneho rozsahu jako (ne)znalosti Javy a nebranim se oznaceni 97% zacatecnik. Uz je to opraveno, ale gramatickych chyb tam bude asi mnohem vic.

[Daniel Kvasnička ml.]

Dobry pocin. Chvalim kazdy blogpost nebo clanek, ktery se podili na rozptylovani predsudku, ze JEE je nepouzitelny moloch pro masochisty