Cool Security Feature in MVC 1.0

If you are developing web applications, sooner or later you will come across something called Cross Site Request Forgery. The most common way to prevent CSRF attacks is by embedding additional, difficult-to-guess data fields, or tokens, in requests containing sensitive data.

Support for CSRF protection has been added to the MVC 1.0 specification. It goes like this:

First, enable CSRF Protection in your application configuration by setting the javax.mvc.security.CsrfProtection to either CsrfOptions.EXPLICIT or CsrfOptions.IMPLICIT.

@ApplicationPath("mvc")
public class MyApplication extends Application {

    @Override
    public Map<String, Object> getProperties() {
        final Map<String, Object> map = new HashMap<>();
       
        // explicit CSRF Protection
        map.put(Csrf.CSRF_PROTECTION, Csrf.CsrfOptions.EXPLICIT);
        return map;
    }
}

Then add the CSRF token to your forms. The Csrf object is available in Expression Language as mvc.csrf .

<form name="form" action="" method="post">
   ...
   <input type="hidden" name="${mvc.csrf.name}" value="${mvc.csrf.token}"/>
</form>

If CsrfOptions.IMPLICIT is used, you’re done. All controller methods annotated with @POST and that consumes the media type x-www-form-urlencoded will be automatically checked for a valid CSRF token.

If CsrfOptions.EXPLICIT is used, then the  @CsrfValid annotation must be added exlicitly to the methods you want the CSRF token to be validated.

@CsrfValid
@POST
@Path("new")
public Response createReservation(@BeanParam FormBean form) {
   // your controller implementation
}

And that’s all you need!

JavaOne is all about Community

JavaOne 2015 is a wrap!

2015-10-30 10.10.00

Five days packed with technical sessions, discussions, community building…It is such a blast!

I have heard more than once that this conference is more about the people than the technology. And I totally agree with that.

Since I am pretty heavy involved in the Java Community Process (JCP), many of my activities this year (as last year) was connected to this. I was interviewed on NightHacking about the JCP in general as well as the JSRs I am on the expert group of (368, 371 and 375). I also managed to get in a word or two about Snoop with input from Arun Gupta.

In addition to my planned sessions, CON1615Meet Snoop – a Discovery Service for Java EE and BOF3666How would you like to improve the Java EE Security API, I was also on stage at the CON4176: Introduction to MVC 1.0 (JSR 371).

Thursday morning we had a very productive Face-to-Face meeting in the JMS 2.1 Expert Group (JSR 368). The minutes from this meeting can be found here.

Last, but not least, thanks to Tomitribe for gathering together the #usualsuspects and making sure everyone is having a good time.

Meet Snoop @ JavaOne

JavaOne in San Francisco is less than a month away. If you have not registered yet, do so now!

j1-468x60-2590159

So far so good! Then you will need to add sessions you want to attend to to your personal schedule. Make sure you don’t wait until the last moment. The most popular sessions tend to fill up pretty fast.

My presentation Meet Snoop – a Discovery Service for Java EE may be can be found in the Schedule Builder by searching for CON1615. Add it to your schedule so that you are sure to get a seat. It may fill up…

Snoop 1.0.0 Released

Snoop..what…?

An explanation may be in order. Snoop is an experimental open source discovery service for Java EE that I created as a demo for my presentation at JavaLand earlier this year. After that I have developed it a little further and now I deem it good enough to be showcased more publicly.

The artifacts are published in Maven Central and has the following coordinates:

<dependency>
   <groupId>eu.agilejava</groupId>
   <artifactId>snoop</artifactId>
   <version>1.0.0</version>
</dependency>
<dependency>
   <groupId>eu.agilejava</groupId>
   <artifactId>snoop-client</artifactId>
   <version>1.0.0</version>
</dependency>

The Snoop Service is also available in Maven Central and for convenience available as a Docker image.

$ docker run -it -p 8081:8080 ivargrimstad/snoop-service:1.0.0

The GitHub project contains the source code as well as more documentation.

https://github.com/ivargrimstad/snoop

Tech Tip – Running Glassfish Nightly Builds in NetBeans

If you have tried adding a recent nightly build of GlassFish 4.1 to the server configurations in NetBeans, you may have come across the following problem:

glassfish-netbeans-error

The solution is as follows:

cd glassfish4/glassfish/lib/install/applications/__admingui/WEB-INF/lib/
mv console-core-4.2-SNAPSHOT.jar console-4.1.jar

This deficiency of the NetBeans server plugin is covered by Bug #250165

An update from JSR 371 (MVC 1.0)

The work in the Expert Group for JSR 371 progresses and here is a small update. A couple of decisions have been made and the most important one is that the JSR will be layered on top of JAX-RS. The decision was made by voting between this and the alternative of layering it on top of the Servlet API.

What this means for you as a developer is that the stuff you are familiar with from JAX-RS is directly transferable to MVC. As you can see in the simple example below, the only thing that differs from JAX-RS is the @Controller and @View annotations.

Note that this code is highly experimental and will most likely change as the work with the specification continues.

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;

import javax.mvc.Controller;
import javax.mvc.View;

@Path("count")
public class CountController {

   @GET
   @Controller
   @Produces("text/html")
   @Path("{id}")
   @View("counter.jsp")
   public void view(@PathParam("id") String id) {
   }
}

A more complete example with a little more details can be found at https://github.com/ivargrimstad/mvc-samples. I will continue evolving this example as we go.

The latest versions of the spec and reference implementation can be found here:

Tech Tip – Upgrading from WildFly 8.1.0 to WildFly 8.2.0

*** Updated ! ***

I came over this problem when I moved an existing Java EE 7 application from WildFly 8.1.0.Final to 8.2.0.Final.  The application is a pure Java EE 7 application with no external dependencies, so you would think it should run without any changes when upgrading the minor verision of a Java EE 7 compliant application server.

In my code I have a LogProducer which enables me to inject the logger using @Inject and this producer was annotated with the javax.inject.Singleton. This works fine in WildFly 8.1.0.

import java.util.logging.Logger;
import javax.enterprise.inject.Produces;
import javax.inject.Singleton;
import javax.enterprise.inject.spi.InjectionPoint;

@Singleton
public class LogProducer {

   @Produces
   public Logger producer(InjectionPoint ip) {
      return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
   }
}

But when I started it in Wildfly 8.2.0, I got the infamous WELD-001408:

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Logger with qualifiers @Default

The reason for this is that Wildfly 8.2.0 builds upon Weld 2.2 (CDI 1.2), while Wildfly 8.1.0 builds upon Weld 2.1.2 (CDI 1.1). To make the producer work in WildFly 8.2.0, I had to change the annotation to javax.ejb.Singleton.

import java.util.logging.Logger;
import javax.enterprise.inject.Produces;
import javax.ejb.Singleton;
import javax.enterprise.inject.spi.InjectionPoint;

@Singleton
public class LogProducer {

   @Produces
   public Logger producer(InjectionPoint ip) {
      return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
   }
}

As pointed out in the comments, using an EJB as a producer may not be the most efficient or correct way. In this case I prefer to use @ApplicationScoped as shown below.

import java.util.logging.Logger;
import javax.enterprise.inject.Produces;
import javax.enterprice.context.ApplicationScoped;
import javax.enterprise.inject.spi.InjectionPoint;

@ApplicationScoped
public class LogProducer {

   @Produces
   public Logger producer(InjectionPoint ip) {
      return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
   }
}

In the current version of NetBeans (8.0.2), this will produce a warning regarding the injection point, Bug 244173.