Wednesday, 7 November 2012

Customizing Liferay Classes using ext plugin in 6.1

Liferay is highly flexible that developers can override any Liferay class by just replacing them in Ext Plugin. But overriding is not a very good action considering "Open for extension closed for Modification" Principle. 
so in this blog post I am going to show simple steps how to extend a Liferay class. 

Note: use ext plugin  class extension or replacement as a last resort if and only if the same cannot be achieved through hooks or other ways.

Step 1: Create you class by extending the Liferay class.
Step 2: Create a file called ext-spring in folder docroot/WEB-INF/ext-impl/src/META-INF
Step 3: From Liferay source code get the file portal-impl/src/META-INF/portal-spring.xml
Step 4: just copy the bean class you are extending from portal-spring.xml and paste to your ext-spring.xml, change the class name to your new extended class. (please ensure you have the <beans> outer tag too in ext-spring as in portal-spring)
step 5: deploy your ext, now Liferay will call your class instead of its own implementation.

Monday, 5 November 2012

Adding JQuery Library to Liferay 6.1 at Portal level

As all Liferay developers know, Liferay 5.2.x and earlier had included jQuery library by default at Portal level, so if we want to use jQuery in any portlet or plugins, we do not need to include the library. But from 6.0, Liferay is using YUI, so jQuery is not available by default and we need to include the jQuery library if we want to use.

The following blog entry from Liferay covers three different ways to include jQuery

http://www.liferay.com/web/nathan.cavanaugh/blog/-/blogs/5363997

1. Theme Level
2. Portlet Level
3. jsp level.

but I came across one scenario where we wanted to have the same behavior as in 5.2.3, we have multiple themes so we do not want to duplicate same code in every portlet, and want to include the jQuery at portal level..

The solution worked for us is

Step 1: included the jquery-1.2.6.min.js in your hook - /jsp-hook/docroot/WEB-INF/ext-web/docroot/html/js/jquery-1.2.6.min.js


Step 2: copy top_js.jspf from source and place that in your hook -  /jsp-hook/docroot/META-INF/custom_jsps/html/common/themes/ and add the the line

            <script src="/html/js/jquery-1.2.6.min.js"></script>

at the end of top_js.jspf.

so now jQuery available throughout the portal in all the themes. 

Monday, 3 September 2012

Is Chrome more secure than other Browsers in XSS attacks

I come across one interesting thing today, looks like Chrome and Safari are more advanced in preventing XSS attacks  than other browsers. To check this, write a small submit form as  below

Test1.jsp

 <body>  
  <form method="get" action="test2.jsp">  
      Attack using this box : <input type="text" name="attack"/>  
      <input type="submit"/>  
  </form>  
 </body>  

and a page to handle the submit

Test2.jsp

 <%=request.getParameter("attack")%>  

open the first one in a browser --> enter "<script> alert('hi......'); </script>" in the text box --> submit.

IE, Firefox, Opera - will show you an alert box with message "hi......"
Chrome and Safari - will not show anything but a blank screen.

In Chrome Console you can see the below error,

Refused to execute a JavaScript script. Source code of script found within request.

chrome detects the same source code in request and response and prevents the XSS attack. Same for Post method too.

Wednesday, 16 May 2012

adding set methods in JAXB for collections

Normally the JAXB generated classes will not contain set methods for collections. (The idea here is to access collections only using get as the basis assumption is the change only happens to the contents of the collection).

if you use the maven maven-jaxb2-plugin, then you can use collection-setter-injector plugin along with jaxb2 plugin to create set methods. Below is a sample configuration,


<plugin>

<groupId>org.jvnet.jaxb2.maven2</groupId>

<artifactId>maven-jaxb2-plugin</artifactId>

<executions>

<execution>

<goals>

<goal>generate</goal>

</goals>

<phase>generate-sources</phase>

</execution>

</executions>

<configuration>

<!-- This helps generate setter methods-->

<args>

<arg>-npa</arg>

<arg>-Xcollection-setter-injector</arg>

</args>

<extension>true</extension>

<episode>true</episode>

<plugins>

<!-- plugin to generate setter for collection-->

<plugin>

<groupId>net.java.dev.vcc.thirdparty</groupId>

<artifactId>collection-setter-injector</artifactId>

<version>0.5.0-1</version>

</plugin>

</plugins>          

</configuration>

</plugin>

Thursday, 12 April 2012

adding a new column as primary key in existing table

Today I come across a little tricky situation to add new column to existing table and make it as a primary key in MS SQL server, the solution is luckily simple,


 alter table my_table add [my_new_id] [int] IDENTITY(1,1);  
 alter table my_table add constraint pk_my_id primary key(my_new_id);  


if you already have a primary key, just remove that and add this new primary key.

Wednesday, 11 April 2012

Running Multiple SoapUI Mock Services from single Maven pom


Sometimes we may need to run multiple SoapUI mock services as part of Test cases, usually if we start multiple mock services from SoapUI, all will start in the same port, but for some reason it is not supported when we start as part of maven execution. Below is the pom entry which is used to start two or more mock services in different ports.

<plugin>
        <groupId>eviware</groupId>
          <artifactId>maven-soapui-plugin</artifactId>         
          <executions>
            <execution>
              <id>soapui-test1</id>
              <phase>test</phase>
              <goals>
                <goal>mock</goal>
              </goals>
              <configuration>            
                   <projectFile>target/mock-project1.xml</projectFile>
                   <port>8088</port>
                   <noBlock>true</noBlock>
                 </configuration>
            </execution>
            <execution>
              <id>soapui-test2</id>
              <phase>test</phase>
              <goals>
                <goal>mock</goal>
              </goals>
             <configuration>           
                   <projectFile>target/mock-project2.xml</projectFile>
                   <port>8089</port>
                   <noBlock>true</noBlock>
                 </configuration>             
            </execution>
          </executions>
        </plugin>

Monday, 9 April 2012

Secure your web apps with HDIV


Recently integrated hdiv framework into the web application I am working on.

We had already had taken enough safety measures to secure the web application, like

1. Always encoding the outputs (like always output from jsp using <C:out> with xml encoding instead of just printing them)
2. Code to secure against SQL injections
3. etc. 

But HDIV is an interesting framework, it seamlessly integrates with the existing application, no need to change the existing code (most of the time) and secures web application mainly against following attacks.

1. Cross site Scripting
2. SQL Injections
3. URL Tampering (I really like this protection, IMO only the links in the web site should be used for navigation, user should not be able to change the URL, especially the values in the path to navigate)
4. Spring bean auto binding, etc.

There are good documents about HDIV in its website hdiv.org, but did found much documentation about its integration with existing applications. So decided to explore my self and found an interesting example implementation at https://github.com/hdiv/hdiv-spring-mvc-showcase, downloaded that and explored, it is really awesome. So I am documenting some simple steps to integrate hdiv with your existing spring application.

Step 1: Dependencies

Include following dependencies in your project, for maven,

        <dependency>
                 <groupId>org.hdiv</groupId>
                   <artifactId>hdiv-core</artifactId>
                   <version>2.1.1</version>
          </dependency>
          <dependency>
                   <groupId>org.hdiv</groupId>
               <artifactId>hdiv-config</artifactId>
               <version>2.1.1</version>
          </dependency>
          <dependency>
                   <groupId>org.hdiv</groupId>
                   <artifactId>hdiv-spring-mvc</artifactId>
                   <version>2.1.1</version>
          </dependency>
          <dependency>
                   <groupId>org.hdiv</groupId>
                <artifactId>hdiv-jstl-taglibs-1.2</artifactId>
                 <version>2.1.1</version>
         </dependency>

Step 2: HDIV-Config.xml

Copy hdiv-config.xml to your resource folder(alternatively classpath, sample found in the showcase app)
see details about hdiv-config at bottom of this post.

Step 3:  web.xml Changes
Step 3.1

Include hdiv-config.xml in context config location as

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
               classpath:/spring-context.xml
               classpath:/hdiv-config.xml
        </param-value>
    </context-param>

Step 3.2

include following hdiv specific entries as,

    <!-- HDIV Init Listener -->
    <listener>
        <listener-class>org.hdiv.listener.InitListener</listener-class>
    </listener>
    <!-- HDIV Validator Filter -->
    <filter>
        <filter-name>ValidatorFilter</filter-name>
        <filter-class>org.hdiv.filter.ValidatorFilter</filter-class>
     </filter>
     <filter-mapping>
        <filter-name>ValidatorFilter</filter-name>
        <servlet-name>dispatcher</servlet-name>
     </filter-mapping>

here dispatcher is the nothing but spring dispatcher servlet, example

    <servlet>
        <servlet-name>dispatcher</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    </servlet>

Step 3.3

 point JSTL to hdiv customized JSTL tag library.

    <jsp-config>
        <taglib>
           <taglib-uri>http://java.sun.com/jsp/jstl/core</taglib-uri>
           <taglib-location>/WEB-INF/tlds/hdiv-c.tld</taglib-location>
        </taglib>
    </jsp-config>                    


Step 4: copy hdiv-c.tld to web-inf

copy the hdiv-c.tld from sample app to web-inf/tlds folder

Step 5: Create your initial landing page

HDIV protected site always expects an HDIV state code to validate the page, if you are trying to access any page without hdiv state it will redirect you to the error page, so we have to create some initial landing page which redirect to other page with hdiv state, following is an sample jsp for initial landing page

name: index.jsp

<body>
        <c:redirect url="login/login.html"></c:redirect>
</body> 
</html> 

include this file in welcome pages list in web.xml and place it in the root folder and add the root folder as starting pages folder in hdiv-config.xml, example 

<hdiv:config errorPage="/error.jsp">
    <hdiv:startPages>/</hdiv:startPages>
     <hdiv:paramsWithoutValidation>
          <hdiv:mapping url="/job/[0-9]*/.*/update.ht"  parameters=".*"/>
     </hdiv:paramsWithoutValidation>         
</hdiv:config>

All the files in the root folder(/) is considered as landing or starting page, so will be exampted from validation for hdiv state.

Important points:

1. Spring tags 3.0 and later has build in support for hdiv, so they can be simple used along with hdiv, but to use previous versions of spring tags, you may need to point your tlds to customized spring tlds, please refer the hdiv document for more details.

2. When using along with spring security or other frameworks which intercept the request and redirects to different pages, special care should be given otherwise it will end up in indefinite redirection loops. I had spring security in the project, so moved all the spring security related files(login, logout, etc) to different path which will not be intercepted by hdiv for more clarity. 

3. whenever accessing hdiv protected paths from non protected paths always use redirects as mentioned in the landing pages step above.


Some Points on hdiv-config.xml

There are three main sections in this file

1. <hdiv:config> section, which is  used to configure the start pages path, error page and validation exceptions 

2. <hdiv:validation> section, which is used to define the acceptable input formats 

3. <hdiv:editableValidations> section, which is used to associate the validations defined in <hdiv:validation> section with paths.

HDIV is really an added protection to the sites, developers may miss few things when protecting the site. By using a framework like HDIV, developers can concentrate more on building the logic than protecting each and every page. 

Give a try, post comment on how you go....






Monday, 19 March 2012

Maven Shortcuts

Maven is cool, but repeatably typing the long maven commands is little bit boring and waste of time. one simple solution is to create set of batch files for the repeatably used commands.

Most of us use our own set of batch files, I thought of organizing them in single place (atleast for me whenever I move to new project I don't need to create my own batch files again and again). I have created a project in github for this purpose and have included very minimum number of very frequently used commands.

The project located at https://github.com/nutpan/Maven-Shortcuts

you can download that and place it your classpath to save your time with maven commands.

Purposefully I have kept the number of commands as minimum, please send me your frequently used commands by raising a issue at https://github.com/nutpan/Maven-Shortcuts/issues or by adding a comment here, I would like to grow the collection in this way on need basis, so that it will have only the most wanted comments.

Below are the shortcuts and their actual maven command


mvnc - mvn clean
mvni - mvn install

mvnci - mvn clean install
mvnciwt - mvn clean install with out tests
mvnt - mvn test
mvnt %1 - mvn test on single test file (eg : mvnt MyTest)
mvnee - mvn eclipse:eclipse


For Windows, copy all the batch files in to a folder and add the folder in classpath
For linux/unix, you can copy the sh files into bin folder and give executable permission using commands in makeItExec.sh

Sunday, 18 March 2012

Liquibase Maven Plugin - Issue with non local database

There is an option in Liquibase to prompt for permission if the database it connects to is not in local system.
By default this option is turned off as per the Liquibase documentation, but when execute through maven Liquibase plugin seems like this default is other way round and by default it is true and even if add the property

promptOnNonLocalDatabase=false


to liquibase properties file, it is not changing its behavior, when we execute this in non head environments like unix, it does through following exception


No X11 DISPLAY variable WAS set, this program aims Performed year operation Which
Requires it.
at java.awt.GraphicsEnvironment.checkHeadless (GraphicsEnvironment.java: 159)
at java.awt.Window.(Window.java: 407)
at java.awt.Frame.(Frame.java: 402)
at java.awt.Frame.(Frame.java: 367)
at $ javax.swing.SwingUtilities SharedOwnerFrame.(SwingUtilities.java: 1731)
at javax.swing.SwingUtilities.getSharedOwnerFrame (SwingUtilities.java: 1808)
at javax.swing.JOptionPane.getRootFrame (JOptionPane.java: 1673)
at javax.swing.JOptionPane.showOptionDialog (JOptionPane.java: 846)
at javax.swing.JOptionPane.showConfirmDialog (JOptionPane.java: 779)
at javax.swing.JOptionPane.showConfirmDialog (JOptionPane.java: 741)
at liquibase.SwingUIFacade.promptForNonLocalDatabase (SwingUIFacade.java: 15)



Solution to this problem is ,


Just add the following in to the maven plugin configuration section

  <promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>

Example :


<build>
      <plugins>
        <plugin>
          <groupId>org.liquibase</groupId>
          <artifactId>liquibase-maven-plugin</artifactId>
          <version>2.0.1</version>
          <executions>
            <execution>
              <phase>process-resources</phase>
              <configuration>
                <propertyFile>target/classes/liquibase.properties</propertyFile>
                <promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
              </configuration>
              <goals>
                <goal>update</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>

Hope this helps....

Thursday, 1 March 2012

Mock Testing for Java Mail

Testing the email related code comes with its own challenges,
  • we may need a dedicated test mail server with test mail box
  • verification part of the test can not be executed right after the setup of test due to the latency in the mail delivery (due to milliseconds delay the test may fail).
  • setup and maintenance may cost its own penalties
Especially in CI and Unit testing, testing email part of the code is not so easy.

There are few good alternatives with Mock Mail testing, one of the interesting and very handy options is Mock-JavaMail. It does not require any additional setup or configuration, just drop the jar into classpath, that's all it requires. 

It redirects all the mails to in-memory mail box which can be easily used in unit tests.

Lets see this with small example. 

Maven Dependency configuration 

Include the following dependency in maven (if not using maven, just drop the jar to classpath)

               <dependency>
        <groupId>org.jvnet.mock-javamail</groupId>
  <artifactId>mock-javamail</artifactId>
  <version>1.9</version>
  <scope>test</scope>
  </dependency>

Example Mail Code

I have used Apache Commons Mail api for this example for simplicity, but works fine with any implementation of Java Mail.

package com.nutpan.example;

import org.apache.commons.mail.Email;
import org.apache.commons.mail.EmailException;
import org.apache.commons.mail.SimpleEmail;

public class MyMailSender {

public void sendMail(String to, String from, String subject, String msg) throws EmailException {
Email email = new SimpleEmail();
email.addTo(to);
email.setFrom(from);
email.setSubject(subject);
email.setMsg(msg);
email.setHostName("testmail.com");
email.send();
}

}

JUnit Test Code

package com.nutpan.example;
import static junit.framework.Assert.assertEquals;
import static junit.framework.Assert.assertTrue;

import java.io.IOException;
import java.util.List;
import java.util.Properties;

import javax.mail.Folder;
import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.Session;
import javax.mail.Store;

import org.apache.commons.mail.EmailException;
import org.junit.Before;
import org.junit.Test;
import org.jvnet.mock_javamail.Mailbox;


public class MyMailSenderTest {

private MyMailSender mailSender;

@Before
public void setUp() {
mailSender = new MyMailSender();
//clear Mock JavaMail box
Mailbox.clearAll();
}

@Test
public void testSendInRegualarJavaMail() throws MessagingException, IOException, EmailException {

String subject = "Test1";
String body = "Test Message1";
mailSender.sendMail("test.dest@nutpan.com", "test.src@nutpan.com", subject, body);
Session session = Session.getDefaultInstance(new Properties());
Store store = session.getStore("pop3");
store.connect("nutpan.com", "test.dest", "password");

Folder folder = store.getFolder("inbox");

folder.open(Folder.READ_ONLY);
Message[] msg = folder.getMessages();

assertTrue(msg.length == 1);
assertEquals(subject, msg[0].getSubject());
assertEquals(body, msg[0].getContent());
folder.close(true);
store.close();
}

@Test
public void testSendInMockWay() throws MessagingException, IOException, EmailException {

String subject = "Test2";
String body = "Test Message2";
mailSender.sendMail("test.dest@nutpan.com", "test.src@nutpan.com", subject, body);
List<Message> inbox = Mailbox.get("test.dest@nutpan.com");
assertTrue(inbox.size() == 1);
assertEquals(subject, inbox.get(0).getSubject());
assertEquals(body, inbox.get(0).getContent());

}
}


First Test uses the regular Javamail approach for reading the mail and the other one uses the Mock-JavaMail  approach to read the mails from the Mock Email Server. I have included the whole import statements to show the different apis from where the classes imported (JavaMail and some from Mock-JavaMail).

You can get more information about this work at 

http://java.net/projects/mock-javamail

There are few more alternatives too, following are some of the few

Wiser
dumbster
Aspirin


give a try and keep me posted.... Better tests better software... 

Tuesday, 7 February 2012

Backref Hibernate exception


One of the possible reasons for

org.hibernate.PropertyValueException: not-null property references a null or transient value: com.server.X._YBackref

is cascading same data multiple time.

For Example you have have two classes

Class Person {
List<Car> carsOwned;
Car preferredCar;
….
}

Class Car {
….
}

And the mapping

<bag name="carsOwned" table="person_cars" access="property" cascade="all,delete-orphan">
   <key column="person_id" not-null="true" update="false" />
   <one-to-many class="Car" />     
</bag>

<many-to-one name="preferredCar" class="Car" column="preferred_car_id" not-null="false" unique="true" cascade="all,delete-orphan" />

In this case you may get the : not-null property references a null or transient value: com.server.X._YBackref exception.

It is because the same car is referred from two fields and both are trying to save/update.
The solution to this problem is change the preferredCar mapping as

<many-to-one name="preferredCar" class="Car" column="preferred_car_id" not-null="false" unique="true" cascade="none" />