Archive for March, 2010

3D Secure and the PaReq field in Google Chrome & Safari Browsers

I recently had to implement the 3D Secure payment system.

In order to do this 3 fields must be sent to the 3D Secure ACS (Access Control Server)

  • MD
  • Term Url
  • PaReq (Payer authentication request)

Initally everything went well until we tested our pages in Google Chrome and Safari. Under both browsers the 3D Secure inline frame displayed the following message

“Error decoding PAREQ message”

A support page mentions that a PaReq contains newlines and that if any of these are missing the PaReq decoding will fail. The page also mentions that there are issues with Chrome and Safari but provides no solution.

So what is the problem?

The problem is indeed the newline.

In our markup we use and EL (Expression Language) to output the PaReq e.g.

<input type="hidden" name="PaReq" value="#{paReq}" />

If the PaReq returned a string such as

"I am
The PaReq
"

Note the quotes above mark the begining and end of the string. The string itself is terminated by a newline, in code it would be:

String paReq = "I am\nThe PaReq\n";

The browser should generate the following markup

<input type="hidden" name="PaReq" value="I am
The PaReq
" />

However Chrome and Safari generate the following markup (as both browsers do this I assume its a Webkit thing)

<input type="hidden" name="PaReq" value="I am
The PaReq" />

Note, the traililng newline has disappeared and herein lies the problem, the server fails to recoginse the PaReq as the trailing newline has gone (currently Chrome 4.0.429.89 contains the above bug).

The fix? Dont use Chrome or Safari, Only kidding

The way we overcame this was to use a “hidden” textarea

<textarea name="PaReq" style="display:none">#{paReq}</textarea>

Which renders

<textarea name="PaReq" style="display:none">I am
The PaReq
</textarea>

In all browsers and preserves the trailing newline. The style=”display:none” hides the textarea. Although this is crude it does provide a fix for Chrome and Safari.

Suppress logging in java unit tests

Here are a couple of different ways of suppressing logging when running unit tests. If you are using apache commons logging then you can suppress logging with the following code:

LogFactory.getFactory().setAttribute(
                "org.apache.commons.logging.Log",
                "org.apache.commons.logging.impl.NoOpLog");

If running your unit tests with JUnit, it is probably best to put this code in the setUp() method. However, if you only wanted it suppressed on particular tests, it could go at the top of the test method instead. Bear in mind that if the logger is a static in the class you are testing, you  may need to then reset the attribute at the end of the test method, otherwise, any tests being run after that one will also have their logging suppressed.

If you run your unit tests within an IDE, you may want to see the logging, but not see the logging when you actually run the build of your project with something like Maven. Thankfully, there is a very simple answer to this if you are using Maven. The maven-surefire-plugin is responsible for running the tests and there is a configuration option which needs to be specified to redirect all the test output to file instead of to the console. This keeps your build reports much cleaner as you aren’t interested in seeing the logging messages. As a bonus, since all output is saved to file, exceptions will also be output to file, so whenever exceptions are thrown in the methods being tested, the stack trace wont show up in the build report.

The configuration option that needs specifying is <redirectTestOutputToFile> and this needs to be set to true, as shown below.

<plugin>
	<artifactId>maven-surefire-plugin</artifactId>
	<configuration>
		<redirectTestOutputToFile>true</redirectTestOutputToFile>
	</configuration>
</plugin>