Implementing Captcha Control with JSF 2.0

This post is in continuation with my previous post related to custom controls. Now comes the part where I will make a practical use of my knowledge.

JSF is all about rich web development. And in today's www world to differentiate between a human and a bot is very difficult. So in order to avoid spam and unnecessary traffic comes into picture Captcha.

I will start by first introducing on how to get started with Captcha:

1. First of all the user who wants to use captcha service need to have a Google Account.
2. Visit the site: reCAPTCHA website. 
3. Login into your google account.
4. Once the reCaptcha signup form is submitted, a page will be shown saying that:

This screen shows that you have successfully setup you captcha account.

Now in order to integrate captcha with your JSF-2.0 application.

It is required to do atleast one of the following:

1. Add the HTML code as is, and then turn you head up and down, to work it in sync with the JSF view.
2. Write a custom control which will do the part of generating the Captcha HTML for me, so I have a clean views to maintain and is easily manageable. (Winner for me :))

So in order to begin with this integration into a JSF web-application following steps are required:

• Get the required library for captcha integration:
• Create a custom Faces Component for captcha rendering:
• Adding the component in faces-config.xml
• Register the control in tag in the taglib.
• Register the taglib in web.xml
• Activate the taglib in faces.
• Create a validator to actually validate the captcha with Google API for Captcha
• Create a sample test page.

 So now I will take one step at a time:

Get captcha dependency:

For maven users, simply add this dependency in your pom.xml:

<dependency>
     <groupId>net.tanesha.recaptcha4j</groupId>
     <artifactId>recaptcha4j</artifactId>
     <version>0.0.7</version>
</dependency>

For non-maven users the jar is available for download here.

Once the jar is included in the classpath. We are ready to move to step-2.

Create custom Faces Component:

For the same I have posted the code below in the file, RecaptchaComponent.java
Don't foget to have a look at the overriden method public void validate(FacesContext ctx);
I will discuss the details later once, I have written the validator.

Adding the component in faces-config.xml

No we do not need to do it here, because the component class is already being annotated with @FacesComponent, so no need to do in faces-config.xml. Both the approaches are alternatives of each other.

Register the control in tag in the taglib:

Since we need to use this control as a tag inside the XHTMLs so it is required that we register the same. For this refer to taglib.xml, as shown in the code below.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE facelet-taglib PUBLIC
"-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
"http://java.sun.com/dtd/facelet-taglib_1_0.dtd">

<facelet-taglib>
    <namespace>http://himanshu/jsf-custom-components/</namespace>
    <tag>
    <tag-name>recaptcha</tag-name>
    <component>
    <component-type>com.himanshu.jsf.custom.recaptcha</component-type>
    </component>
    </tag>
</facelet-taglib>


Register the taglib in web.xml and Activate the taglib in faces:

Both these steps can be merged into a single step, with the following tags in web.xml.


<context-param>
<param-name>javax.faces.FACELETS_LIBRARIES</param-name>
<param-value>/WEB-INF/marquee-taglib.xml</param-value>
</context-param>



Create a validator to actually validate the captcha with Google API for Captcha:

We have created a custom validator which will capture the request, get the input entered in the captcha control. And will validate it using Google API for captcha (RecaptchaValidator.java)

And we are done.

Now its time to test: 


<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:customJSF="http://himanshu/jsf-custom-components/">

<f:view>
<h:head></h:head>

    <h:form id>
              

<customJSF:recaptcha id="rc" publicKey="abc" privateKey="xyz">

<f:validator validatorId="com.himanshu.jsf.captcha.validator" />
      </customJSF:recaptcha>

      <h:message for="rc" />
              
              <h:commandButton type="submit" id="login" value="Login" action="#{helloWorld.submitForm}" />

        </h:form>

</f:view>
</ui:composition>


Build the application and deploy in AS.
This will render the captcha control once the corresponding view is opened.

Here is the sample captcha generated.

But wait a minute, my validator is not getting called. Did I miss something?

Now let me rollback to the point where I had to override validate method in RecaptchaComponent.java.

Why did we do that, this was done basically because:
Validators are by default or by configuration not invoked when the value is empty. For that, either the required attribute should be used, or the javax.faces.VALIDATE_EMPTY_FIELDS context param should be set with a value of true.

That was the case here. So overriding the validate method and calling the validator registered with the RecpatchaComponent serves the purpose here.

Now we are done with developing the captcha component for JSF-2.0 and ready to integrate in our application.

Writing Custom components for JSF-2.0

With the introduction of JSF-2 along came some feature which were simplified. One such feature is creation of custom JSF components.


Why is it required?

Well one reason for it is that is wrapping up the tag which is complex in itself. To make it more simple to use and user-friendly.

Consider a simple case:
I need to have a marquee component, in which I will just mention the string which will be floated in my HTML and the rest will be done component renderer itself.

How is it done?

So first of all in order to make this work, we need to understand what all files we need to create or update.

(MarqueeComponent.java) First of all we need to extend "javax.faces.component.UIComponentBase", extending this class gives us the methods which are used to translate a tag into its HTML equivalent. Look at the annotation @FacesComponent, using this we declare the component type, which is then used in faces-config.xml for declaring the component.


(faces-config.xml) After extending UIComponentBase class, it was required to communicate to JSF that a custom component is created the configuration for the same is mentioned below in the code snippets.

NOTE: You need to configure component in faces-config.xml, iff @FacesComponent is not being used to register the component. @FacesComponent and <component> tag in faces-config.xml are alternatives of each other. @henk, Thanks for pointing out.


(marquee-taglib.xml) And the next part is to create a taglib for the same so that we can use the tags JSF files. As once taglibs are loaded in web-application then only we can use those tags.


(web.xml - snippet) But still one part is missing, we still haven't mentioned the part where we are supposed to load the taglibs in the web-application. For the same, we need to mention the taglib file in web.xml, under context param javax.faces.FACELETS_LIBRARIES 

(sample.xhtml) A sample to demonstrate the custom tag.

Code

How to write a Custom Codec in Apache MINA?

Whenever we have to develop a socket based enterprise application. Few frameworks come to our mind. To name a few:

• Netty
• Apache MINA

If I go by the book,

Netty:

Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server.

'Quick and easy' doesn't mean that a resulting application will suffer from a maintainability or a performance issue. Netty has been designed carefully with the experiences earned from the implementation of a lot of protocols such as FTP, SMTP, HTTP, and various binary and text-based legacy protocols. As a result, Netty has succeeded to find a way to achieve ease of development, performance, stability, and flexibility without a compromise.

Whereas,

Apache MINA:

Is a network application framework which helps users develop high performance and high scalability network applications easily. It provides an abstract event-driven asynchronous API over various transports such as TCP/IP and UDP/IP via Java NIO.

Data Packets:

If I talk about sending packets over network there are mainly two approaches being used:

1. Connect - Send - Process - ByeBye
• Client make a socket connection with server 
• Sends data over the channel 
• Server Processes it
• Send results or acknowledgement
• Objective complete socket closed
2. Connect - Send - Process - Send ... and so on
• Client establishes the connection for the first time with server
• Sends data over the channel
• Server Processes it
• Send results or acknowledgement
• Channel still remains open for further communication.

Now we have the question which approach to go for, remember both approaches have its pros and cons.

Lets first discuss:

There's always an overhead of socket connections establishment. If same client keeps on sending a large number of packets, then we will be wasting considerable CPU cycles in this process. So if we have certain specific number of client only then we can think of moving to approach#2

But if we have large number of clients then we can say approach#2 will easily become the cause of bottleneck.

Now lets come to the main reason why this blog is written, there can be a number of times that while doing socket connections, developer have to create their own protocol for the clients. This gives independence of customization.

But if I merge approach#2 for socket communication with custom protocol, well that's definitely something to look at.

I am going to explain the method of writing a custom codec with Encoder and Decoder. This is somewhat I did though I changed the actual protocol because of some reasons I can't disclode ;) .

The code appears to be self explanatory, but I would still like to put up few points.
Here I have used cumulative protocol, because I might required more packets for merging in order to get complete information. 

I am open to inputs as well as if anyone want more details.