Spring Security: Invalid CSRF Token ‘null’ was found on the request parameter ‘_csrf’ or header ‘X-CSRF-TOKEN’

PROBLEM

With Spring Security 4.x, the CSRF protection is enabled by default. You may disable it, but to be more aligned with OWASP and the industry security standard, it’s best to leave this setting the way it is. Learn more about CSRF attack…

To prevent this attack, Spring Security 4.x requires you to attach a server-side generated CSRF token on any POST, PUT or DELETE calls… basically, actions that may modify the request state. Their argument for not attaching this token on GET is to prevent this token value from leaking out.

Further, you will require to call POST /login and POST /logout now. In the past, you can call GET /j_spring_security_logout without problem.

If you invoke POST, PUT or DELETE without this CSRF token, you will get a 403 error with this message: "Invalid CSRF Token 'null' was found on the request parameter '_csrf' or header 'X-CSRF-TOKEN'.".

SOLUTION

To obtain this CSRF token, add this Spring Security custom tag to the JSP file:-

<!DOCTYPE html>
<html>
	<head>
	    <sec:csrfMetaTags/>
	</head>
	<body>
	</body>
</html>

The rendered HTML looks like this:-

<!DOCTYPE html>
<html class="no-js">
	<head>
	    <meta name="_csrf_parameter" content="_csrf" />
	    <meta name="_csrf_header" content="X-CSRF-TOKEN" />
	    <meta name="_csrf" content="e62835df-f1a0-49ea-bce7-bf96f998119c" />
	</head>
	<body>
	</body>
</html>

Finally, set the request header before making the AJAX call:-

var header = $("meta[name='_csrf_header']").attr("content");
var token = $("meta[name='_csrf']").attr("content");

$.ajax({
    url: '/test',
    type: 'POST',
    beforeSend: function(xhr){
        xhr.setRequestHeader(header, token);
    },
    success: function(data) {
        console.log(data);
    },
    error: function (xhr, ajaxOptions, thrownError) {
        console.log(xhr.status + ": " + thrownError);
    }
});

Jackson 2.x: JSON Serialization Difference for Map.Entry between 2.4.x vs 2.5.x

It appears Jackson 2.4.5 and 2.5.1 behave a little differently when handling Map.Entry.

Let’s assume we have the following bean:-

public class MyBean {
    private Map.Entry<String, String> entry;

    public Map.Entry<String, String> getEntry() {
        return entry;
    }

    public void setEntry(Map.Entry<String, String> entry) {
        this.entry = entry;
    }
}

We have a simple Spring MVC rest controller that creates this bean and returns the JSON data back to the client:-

@RequestMapping(value = "/map", method = RequestMethod.GET)
public ResponseEntity map() {
    final MyBean myBean = new MyBean();
    myBean.setEntry(new AbstractMap.SimpleImmutableEntry<String, String>("a", "1"));

    return new ResponseEntity<MyBean>(myBean, HttpStatus.OK);
}

Jackson 2.4.5 generates the following JSON:-

{
   "entry":
   {
       "key": "a",
       "value": "1"
   }
}

Jackson 2.5.1 generates the following JSON:-

{
   "entry":
   {
       "a": "1"
   }
}

Dang it….

Spring MVC: Handling Joda Data Types as JSON

PROBLEM

Let’s assume we have the following bean that contains Joda’s LocalDate and LocalDateTime objects:-

public class MyBean {
    private LocalDate date;
    private LocalDateTime dateTime;

    public LocalDate getDate() {
        return date;
    }

    public void setDate(LocalDate date) {
        this.date = date;
    }

    public LocalDateTime getDateTime() {
        return dateTime;
    }

    public void setDateTime(LocalDateTime dateTime) {
        this.dateTime = dateTime;
    }
}

This simple Spring MVC rest controller creates this bean and returns the JSON data back to the client:-

@RequestMapping(value = "/joda", method = RequestMethod.GET)
public ResponseEntity joda() {
    MyBean myBean = new MyBean();
    myBean.setDate(LocalDate.now());
    myBean.setDateTime(LocalDateTime.now());
    
    return new ResponseEntity<MyBean>(myBean, HttpStatus.OK);
}

By default, the generated JSON looks like this:-

{
   "date":
   [
       2015,
       3,
       28
   ],
   "dateTime":
   [
       2015,
       3,
       28,
       18,
       12,
       58,
       992
   ]
}

How do we nicely format these values and still retain the correct data types (LocalDate and LocalDateTime) in MyBean instead of writing our custom formatter and store the values as String?

SOLUTION

First, add a dependency for jackson-datatype-joda.

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.5.1</version>
</dependency>
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.5.1</version>
</dependency>
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-annotations</artifactId>
    <version>2.5.1</version>
</dependency>
<dependency>
    <groupId>com.fasterxml.jackson.datatype</groupId>
    <artifactId>jackson-datatype-joda</artifactId>
    <version>2.5.1</version>
</dependency>

Next, instruct MappingJackson2HttpMessageConverter to accept a custom ObjectMapper.

<bean id="objectMapper" class="org.springframework.http.converter.json.Jackson2ObjectMapperFactoryBean"
      p:indentOutput="true" p:simpleDateFormat="yyyy-MM-dd'T'HH:mm:ss.SSSZ">
</bean>

<bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean" p:targetObject-ref="objectMapper"
      p:targetMethod="registerModule">
    <property name="arguments">
        <list>
            <bean class="com.fasterxml.jackson.datatype.joda.JodaModule"/>
        </list>
    </property>
</bean>

<mvc:annotation-driven>
    <mvc:message-converters>
        <bean class="org.springframework.http.converter.StringHttpMessageConverter"/>
        <bean class="org.springframework.http.converter.ResourceHttpMessageConverter"/>
        <bean class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter">
            <property name="objectMapper" ref="objectMapper"/>
        </bean>
    </mvc:message-converters>
</mvc:annotation-driven>

The generated JSON output now looks like this:-

{
   "date": "2015-03-28",
   "dateTime": "2015-03-28T18:11:16.348"
}

Karma: Managing Plugin Versions in package.json

PROBLEM

Let’s assume our package.json looks like this:-

{
  "name": "testKarma",
  "private": true,
  "devDependencies": {
    "karma": "^0.12.24",
    "karma-chrome-launcher": "^0.1.4",
    "karma-coverage": "^0.2.4",
    "karma-jasmine": "^0.2.2",
    "karma-junit-reporter": "^0.2.1",
    "karma-phantomjs-launcher": "^0.1.4"
  }
}

What we want to do is to update all the plugin versions defined in this file.

SOLUTION

After trying out several solutions, it appears that using npm-check-updates is a better and cleaner solution for discovering newer versions of these plugins.

First, we need to install npm-check-updates globally. You may need to use sudo to do so.

sudo npm install -g npm-check-updates

Once installed, run the following command within the project root directory to discover any new versions:-

npm-check-updates

Output:-

"karma-chrome-launcher" can be updated from ^0.1.4 to ^0.1.5 (Installed: 0.1.5, Latest: 0.1.5)
"karma-coverage" can be updated from ^0.2.4 to ^0.2.6 (Installed: 0.2.6, Latest: 0.2.6)
"karma-jasmine" can be updated from ^0.2.2 to ^0.2.3 (Installed: 0.2.3, Latest: 0.2.3)
"karma-junit-reporter" can be updated from ^0.2.1 to ^0.2.2 (Installed: 0.2.2, Latest: 0.2.2)

Run 'npm-check-updates -u' to upgrade your package.json automatically

Finally, run the following command to update the plugins:-

npm-check-updates -u

Output:-

"karma-chrome-launcher" can be updated from ^0.1.4 to ^0.1.5 (Installed: 0.1.5, Latest: 0.1.5)
"karma-coverage" can be updated from ^0.2.4 to ^0.2.6 (Installed: 0.2.6, Latest: 0.2.6)
"karma-jasmine" can be updated from ^0.2.2 to ^0.2.3 (Installed: 0.2.3, Latest: 0.2.3)
"karma-junit-reporter" can be updated from ^0.2.1 to ^0.2.2 (Installed: 0.2.2, Latest: 0.2.2)

package.json upgraded

The plugin versions are successfully updated, and package.json is also updated accordingly.

{
  "name": "testKarma",
  "private": true,
  "devDependencies": {
    "karma": "^0.12.24",
    "karma-chrome-launcher": "^0.1.5",
    "karma-coverage": "^0.2.6",
    "karma-jasmine": "^0.2.3",
    "karma-junit-reporter": "^0.2.2",
    "karma-phantomjs-launcher": "^0.1.4"
  }
}

Why I Am Switching to Karma

OVERVIEW

JavaScript testing is hard. Most of the time, it is just plain difficult to set up the test harness just to run Javascript tests.

CURRENT STATE

Most of my team’s existing production web applications do not use any MV* frameworks. A few newer projects use Backbone/Marionette.

We rely on the following stack:-

We choose this direction because these Maven plugins provide good integration with Jenkins.

What is Wrong with the Current State

FUTURE STATE

We will now rely on the following stack:-

Why This is a Better State

  • Developed by Google developers, primary test harness for AngularJS.
  • Allows us to use Jasmine 2.x.
  • Test framework agnostic. Although we are using Jasmine now, we can easily switch to Mocha in the future.
  • MV* framework agnostic. It works with any MV* or homegrown framework.
  • Great integration with Jenkins.
  • Great integration with IntelliJ.
  • Ability to run tests on different browsers at the same time, such as Chrome, Firefox, PhantomJS, etc.