Nejnovější X.Org X server 21.1.17 a Xwayland 24.1.7 řeší 6 bezpečnostních chyb: CVE-2025-49175, CVE-2025-49176, CVE-2025-49177, CVE-2025-49178, CVE-2025-49179 a CVE-2025-49180. Nils Emmerich je nalezl koncem března a dnes publikoval detaily.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.4 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
UN Open Source Week 2025 probíhá tento týden v sídle Organizace spojených národů v New Yorku. Středeční a čtvrteční jednání bude možné sledovat na UN Web TV.
Byla vydána nová verze 2.50.0 distribuovaného systému správy verzí Git. Přispělo 98 vývojářů, z toho 35 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Infrastrukturu pro chatovací aplikaci Telegram provozuje člověk s vazbami na ruské zpravodajské služby. Upozorňují na to investigativní novináři z redakce iStories. „Vedneev dodává služby ruskému státu včetně jeho jaderného institutu nebo zpravodajské službě FSB,“ říká v podcastu Antivirus novinář Jan Cibulka. Uživatelům, kteří si chtějí své informace chránit, doporučuje Telegram vůbec nepoužívat, a raději zvolit jednu z alternativ, WhatsApp nebo Signal.
The Trump Organization spustila ve Spojených státech mobilní síť Trump Mobile s neomezeným tarifem The 47 Plan za 47,45 dolarů měsíčně a představila vlastní značku telefonů The T1 Phone s Androidem za 499 dolarů.
Vývojáři KiCadu se na svém blogu rozepsali o problémech KiCadu v desktopových prostředích nad Waylandem. KiCad běží, ale s významnými omezeními a problémy, které podstatně zhoršují uživatelský komfort a vývojáři je nedokážou vyřešit na úrovni KiCadu. Pro profesionální používání doporučují desktopová prostředí nad X11.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Byla vydána (𝕏) nová verze 2025.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Dánské ministerstvo pro digitální záležitosti má v plánu přejít na Linux a LibreOffice [It's FOSS News].
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
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.
Tiskni
Sdílej:
V Javě jsem cca 97%-ní začátečník.V češtině asi taky, ne?
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).
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"...