Attempt to prevent XSS in JSP... failed

As every web developer should know, you have to escape untrusted output to prevent Cross-site scripting vulnerabilities. Most web frameworks do it by default, but not JSP. In JSP, you have to do it manually every time, either using <c:out>...</c:out> or ${fn:escapeXml(...)}. Needless to say, it is easy to forget (especially if you are used to modern framework) and it clutters the template.

It feels logical that this problem should have been solved somehow already, given that thousands of developers have been using JSP every day, for years. But I've found only one solution that looks promising: http://pukkaone.github.com/2011/01/03/jsp-cross-site-scripting-elresolver.html.

I've given it a try and found that it basically works as expected. And the most important, you can override the escaping where needed, by using the custom tag. But there are 2 problems that prevented me from using it:

1. The effect of this resolver is global (as expected), so you must remove existing escaping from every JSP where you have it, and re-test the whole application
2. If you use <jsp:include> with parameters (and I use it a lot), you must override escaping of the parameter values, to avoid double escaping

So, while the first problem is solvable (given the time and resources), the second makes the whole solution look doubtful. Instead of being careful to use escaping everywhere, now I need to be careful to override escaping on each <jsp:include>. And again, it creates a lot of clutter.

Map of Android Market supported countries, UPDATED

Good news, the Android Market has expanded list of countries where you can buy paid apps.

Click to see large image

Green countries - users can buy and developers can publish paid apps.
Blue countries - users can buy but developers cannot publish.
Yellow countries - same as blue but for some reason Google calls them "Rest of the world" (maybe some restrictions will apply).

Sadly, no new countries added to support paid apps developers.

ForkingAspect added to Common Spring Aspects

A small but useful addition to the common-spring-aspects project: forked execution of a bean method.

Using the ForkAspect, it is possible to define bean methods to be executed in a separate thread. This is useful to avoid waiting on slow methods whose results we do not actually need to proceed (common examples - email sending, statistics event registration, etc).

NoSuchAlgorithmException: SunTlsRsaPremasterSecret after Java upgrade on Mac OS X

I've this weird problem after upgrading to new Java version on Mac. My (maven) project ran OK from command line but got the "SunTlsRsaPremasterSecret" error in Eclipse.

Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
at javax.crypto.KeyGenerator.<init>(DashoA13*..)
at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
at com.sun.net.ssl.internal.ssl.JsseJce.getKeyGenerator(JsseJce.java:223)
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:89)

The solution was to remove Installed JREs in Eclipse configuration and add them again (using the "Search..." button).

Map of Android Market supported countries

As you might know, Android Market only allows people in certain countries to buy paid apps. Also, developers can only publish those applications if located in supported countries. The list of those countries is published here.

As I'm a visual type of person, I like to see maps. Surprisingly, there is no map of of Android Market supported countries available anywhere yet. So I've created one myself:

(click to see full size)

Developers based in "green" countries can publish paid apps. Users based in "green" or "blue" countries can buy them.

As you see, all the "Western world" is covered. What is notably not covered is Eastern Europe and Asia. And that's unfortunate, as there is a lot of good developers (and potential buyers) in those regions.

Tomcat crashing silently

Sometimes I'm surprised to see strange Tomcat crash - no error message in log, the process just stopped running.

As usual, the root cause is between the keyboard and the chair - I have some infinite loop in the code :)

Too bad that there is no log to give a hint. So the only way to tell is to do remote debugging and find out the code line where the problem occurs.

Of course this can happen also on Jetty, or whatever other servlet container.

Common Spring aspects

It is amazing how many people still write some log.debug() to track execution time of their methods or create a caching proxy class for each class they want to cache.

Come on, this is done million times before, why not reuse ?

Today I've written some documentation on the Common Spring aspects project. This project collects some handy aspects that I find myself using on almost every project - currently, performance logging (using JaMon library) and caching bean method invocations results (using Ehcache). The code itself is fairly small, mostly it just delegates execution to the respective library.