Sunday, July 17, 2011

Character Verification on Registration\Forgot Password | Captcha

Recaptcha is a free solution hosted and owned by Google.
Pros: Widely used in the industry, services based solution really easy to impelemnt
Cons:The biggest minus on this is, if you have a strong firewall policy where the outgoing IP/Ports for app servers are blocked. This solution will not work as the IP addresses will change some times and hence it might not be feasible to dynamically open up the firewalls for the new addresses.
Kaptcha is a free Apache license based java solution works with JDK 1.4.2,
Pros: Really easy to implement and drop the jar files, no external webservices required. if you are using V6 and it also works with later versions of JDK hence this would work for V7. Kaptcha uses pixels and previous versions image libraries to refresh the image.
Cons: Does not support audio.

How to use in commerce?

1. Entry in web.xml for the servlet mapping, make this entry after dynacache and other OOB filters.

2. The default implementation has .jpg but if you are using edge caching such as Akamai, removed tha .jpg.
3. Add the external jar file and making a corresponding entry in META_INF (I have a blog on this for reference
4. The API returns HTML collection, you can access in your javascript as follows:
var kaptchaVariable=document.getElementsByName("kaptcha").item(1).value;
5. If you need to refresh the Kaptcha implement a javascript on click and you can do HTML write attribute.
.writeAttribute('src','/webapp/wcs/stores/kaptcha?' + Math.floor(Math.random()*100) );
6. You can also implement an on the img and use the following method
$(AnchorelementPassed).down().writeAttribute('src', '/webapp/wcs/stores/kaptch?' + Math.floor(Math.random()*100) );
7. You can implement in a ajax call or a command but you can validate in validateParameters.
HttpServletRequest request =
(( this

String kaptchaValueExpected = (String)request.getSession().



  1. Your implementation of Kaptcha is not integrated into the Commerce database, so when you have a clustered stateless solution it won't work - if customer requests may be sent to different servers, they can't communicate which captcha ID is connected to which session?

  2. I have implemented this in a clustered environment and it works. As the cloneId that is associated with a server and JSessionId that is associated with request directs to the appropriate server from which the request originated would take care of that problem.

  3. Ah, OK, not the way we set it up - stateless and basically round robin