Thank you Mr Beck

September 21st, 2014 No comments

Two weeks ago, I was at the JavaZone conference (in Norway) for the first time. There, I facilitated a Vaadin 7 workshop and presented an Introduction to Mutation Testing. Moreover, I attended many great talks by brilliant speakers, but one was really head and shoulders above the lot: “Software Design, Why, When and How” by Kent Beck.

For those of you that don’t know about Mr Beck: he’s the co-author of the JUnit testing framework, he created Extreme Programming, he is at the origin of Test-Driven Development methodologies and much much more… This is just to say that I was expecting much from the talk, especially since Software Design is at the root of most of my work though I’ve been disappointed by so-called “star” speakers in he past.

The first thing to note is that the talk took place in an unusual room, as the stage was set between two opposite sets where half the audience was located. In essence, you could speak only in front of  half the people at any one time. Not an easy feat! Also, I was very surprised by Mr Beck not using any slides in his talk. Of course, he probably had some piece of paper somewhere but the magic is that his talk was very fluid. Given the amount of time it takes me to prepare my talks with slides, I can only wonder at the time it took him to prepare without. In the end, the result was impressive!

The content of the talk, however, was all about a single and very simple message: Software Design is all about context. Sometimes, you need to design upfront, sometimes, it will cost more. Sometimes, it’s better to refactor, sometimes, not. Sometimes, one should refactor now, sometimes later. And so on. In essence, the meme about code duplication being bad is just that, a meme. This is despite the fact that Software Designers need to care about efficiency first and about how to best use scarce resources, i.e. time.

The last part of the talk was devoted to three main qualities of a Software Designer:

  • Tolerance to ambiguity
  • Ability to postpone decisions
  • Social skills [sic]

This talk really stroke a chord in me as my studies were not in Computer Sciences but in Architecture (as in buildings). At this time, I was very pissed off that Architecture was not a real science, that there was no right or wrong answer and that you were never completely sure to have an adequate solution until the thing is finally built. This uncertainty was really a burden at that time, and I went to software development because either my code compiled – or not, and my application produced the expected output – or not. But with Software Design, that’s exactly as in Architecture (as in buildings, remember?), it’s all about context and gut feeling and experience.

All in all, this was really a great show. Even better, I went to him after the talk to tell him about the Architecture stuff and his conclusion is the following:

Good decisions come from experience
Experience come from bad decisions
- Kent Beck at JavaZone

This just exactly match my experience, as I’ve made plenty of bad decisions in my career, so I guess I’ve plenty of material to take good decisions from in the future ;-)

And as for those who want to enjoy the integrality of the talk, here it is in all its glory. Thank you Mr Beck.

Categories: Technical Tags:

Another valid Open/Closed principle

September 15th, 2014 1 comment

I guess many of you readers are familiar with the Open/Closed principle. It states that:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
- Meyer, Bertrand (1988). Object-Oriented Software Construction

This other Open/Closed principle is completely unrelated, but just as important. It states that:

When “something” is opened by one’s code, one MUST close it as well!
-Me (2014). My bathroom

Simple enough? Then why do I regularly stumble upon database connections not closed (i.e. released to the pool), sockets as well, input streams not closed, output streams not closed, etc.? (But to be honest, I also am guilty of sometimes forgetting the later). When resources are not released just after their use, it might generate memory leaks. Other possible consequences are related to the resource’s nature: for example, when not releasing database connections, sooner or later the pool will be exhausted so that no new connections to the database can be acquired – and basically your application will be unusable, requiring a reboot of the application server.

Still, nothing prevents us from taking care of closing the resource, there are just some little things to address:

  1. As seen above, closing a resource is not an option, it must be ensured. Java makes it possible through the finally block (so that a related try block is necessary as well).
  2. Most close() (or release() or destroy() or what have you) method signatures throw a checked exception. If you really want my opinion, this is a design mistake but we developers have to deal with it (and to be honest, this is not the first time someone made a decision where I had to handle the consequences of, that’s know as Management 1.0).

Here’s a very simple example:

File file = new File("/path/to/file");
FileInputStream fis = new FileInputStream(file);
try {
    // Do something with file
} finally {

Note line 6 uses a method whose signature throws a checked exception and must be dealt accordingly. As in most cases, exception thrown while closing hard hardly recoverable (read not at all), not throwing it further is more than a valid option. Instead of further cluttering the code, just use Apache Commons IO‘s IOUtils.closeQuietly() (or its database counterpart Apache Commons DB‘s DBUtils.closeQuitely()).

The finally block above can be replaced as follows:

finally {
    LOGGER.log("Couldn't close input stream on file " + file.getAbsolutePath());

(Yes, logging that a resource cannot be released is a good practice in all cases)

Finally (no pun intended), one might remember that Java 7 brings the AutoCloseable interface along with the try-with-resources syntax. This makes it even simpler to handle the close() if the method signature doesn’t throw an exception:

try (StringReader reader = new StringReader(string)){
    // Do something with reader

(Note StringWriter.close() signature throws an exception, even though it does nothing)

In conclusion, remember that Continuous Integration platforms are your friend and tools such as Sonar (or Checkstyle, PMD and FinddBugs) are a good way to check unreleased resources.

Categories: Java Tags:

The best there is at what it does

September 7th, 2014 No comments

Before anything else, please check the reference to the title if you didn’t get it.

This week, Vaadin released its version 7.3 with the new easily configurable Valo theme. I just had to blog about this on my other blog,, which uses Jekyll as static-site generation engine.  The problem I had to tackle is that not only did I not use Jekyll since 5 months, my laptop had been remastered and I had to re-install the software.

Now, with the help of my friend Google, I managed to install homebrew, rbenv, ruby-build and jekyll (yes, Jekyll is a Ruby gem) in the course of an evening. The same evening, I wrote my blog post, fixed the configuration as well as bad link reference and generated the site. Easy as pie, even though I didn’t touch the thing is so much time!

Today, my thoughts hovered around that fact: it is easy! Just like some other tools – like WordPress, are easy: easy to install, easy to configure and easy to use. In parallel, I thought about the original version of I developed with Drupal. Let me tell you what: Drupal is extremely powerful but is a nightmare to configure. Making the switch from Drupal to Jekyll made my life easier a thousandfold.

The my mind wandered further and drew a parallel between simple programming languages and more powerful ones. This has been my experience when I tried to do some Scala workshop at the beginning of the year: after 6 months, I’ve been able to use only the simplest features, not the most powerful constructs. That had been sorely disappointing to me, as I realized I was worse in Scala than I thought.

I’m aware this parallel might be a little overstretched, however I cannot stop theorizing languages features power can be an asset but also a curse if one has to constantly keep using them to remember them. For example, I think that Java’s syntax is easy enough not only to use but also to remember, though I must conced I might be biased because I have more than 10 years experience developing in that language.

Whatever you design, tool, technique or language, it might be the best at what it does, but please consider that simplicity is a virtue.

Categories: Technical Tags:

Using exceptions when designing an API

August 31st, 2014 2 comments

Many knows the tradeoff of using exceptions while designing an application:

  • On one hand, using try-catch block nicely segregates between regular code and exception handling code
  • On the other hand, using exceptions has a definite performance cost for the JVM

Every time I’ve been facing this quandary, I’ve ruled in favor of the former, because “premature optimization is evil”. However, this week has proved me that exception handling in designing an API is a very serious decision.

I’ve been working to improve the performances of our application and I’ve noticed many silent catches coming from the Spring framework (with the help of the excellent dynaTrace tool). The guilty lines comes from the RequestContext.initContext() method:

if (this.webApplicationContext.containsBean(REQUEST_DATA_VALUE_PROCESSOR_BEAN_NAME)) {
    this.requestDataValueProcessor = this.webApplicationContext.getBean(
    REQUEST_DATA_VALUE_PROCESSOR_BEAN_NAME, RequestDataValueProcessor.class);

Looking at the JavaDocs, it is clear that this method (and the lines above) are called each time the Spring framework handles a request. For web applications under heavy load, this means quite a lot! I provided a pass-through implementation of the RequestDataValueProcessor and patched one node of the cluster. After running more tests, we noticed response times were on average 5% faster on the patched node compared to the un-patched node. This is not my point however.

Should an exception be thrown when the bean is not present in the context? I think not… as the above snippet confirms. Other situations e.g. injecting dependencies, might call for an exception to be thrown, but in this case, it has to be the responsibility of the caller code to throw it or not, depending on the exact situation.

There are plenty of viable alternatives to exceptions throwing:

Returning null
This means the intent of the code is not explicit without looking at the JavaDocs, and so the worst option on our list
Returning an Optional
This makes the intent explicit compared to returning null. Of course, this requires Java 8
Return a Guava’s Optional
For those of us who are not fortunate enough to have Java 8
Returning one’s own Optional
If you don’t use Guava and prefer to embed your own copy of the class instead of relying on an external library
Returning a Try
Cook up something like Scala’s Try, which wraps either (hence its old name – Either) the returned bean or an exception. In this case, however, the exception is not thrown but used like any other object – hence there will be no performance problem.

Conclusion: when designing an API, one should really keep using exceptions for exceptional situations only.

As for the current situation, Spring’s BeanFactory class lies at center of a web of dependencies and its multiple getBean() method implementation cannot be easily replaced with one of the above options without forfeiting backward compatibility. One solution, however, would be to provide additional getBeanSafe() methods (or a better relevant name) using one of the above options, and then replace usage of their original counterpart step by step inside the Spring framework.

Categories: Java Tags: , ,

Past, present and future

August 17th, 2014 3 comments

Dear readers,

This week won’t be a detailed technical article: last week’s was the 250th post on this blog, time for a little introspection, and thinking about the past and future. Speaking about the past, my first post was written on this blog on April 7th 2008 – more than 6 years ago, to announce I had successfully passed the Sun Certified Java Developer 5 :-) At that time, I didn’t really know what a blog was for, I just wanted to have one and I used it sometimes like Twitter today.

The first real technical article was written about the Display taglib on May 23rd of the same year. I guess it was the first that really counted, and I haven’t stopped writing from this point. I love my job – though I’ve changed employers since that time, and all my positions have given me material to blog about. I also try to dabble into unknown territory when I want to understand how software I do not use is working. If you’re a regular visitor, you might have noticed I try to write once per week, though I sometimes cannot hold the rhythm. However, some of you might know I’m currently also writing Integration Testing from the Trenches, which sometimes puts me in a quandary: should I write a new article or write another chapter of the book? So if you want to help me there, don’t forget to get your own copy ;-)

And for the future, well, it looks extremely interesting.

  • At JavaZone (Oslo – Norway), on September 11th, I’ll be holding a workshop on Vaadin. I’ll also use the occasion to give a lightning talk on Mutation Testing
  • I’ll be at JavaDay Kiev (Ukrain), on October 17th-18th for a workshop on Vaadin and a talk about Integration Testing
  • Going to Joker conference (St Petersburg – Russia) on October 20th-21st? Let’s meet there, my exact contributions are to be announced in the near future
  • Finally, I’ll finish October at Agile Tour London on the 24th for a talk about Integration Testing

If you happen to attend any of these events, don’t hesitate to say hello!

Categories: Technical Tags:

Sanitizing webapp outputs as an an afterthought

August 10th, 2014 No comments

For sure, software security should be part of every developer’s requirements: they should be explained and detailed before development. Unfortunately, it happens in real life that this is not always the case. Alternatively, even when it is, developers make mistakes and/or have to make with tight (read impossible) plannings. In the absence of security checks automated tools, sooner or later, an issue will appear.

I’ve been thinking about a way to sanitize the output of a large-scale legacy Spring MVC application in a reliable way (i.e. not go on each page to fix issues). Basically, there are 4 ways output is displayed in the HTML page.

# Name Sample snippet Description
1 Form taglib Outputs a bean attribute
2 Spring taglib Outputs a message from a properties file
3 Java Standard Taglib Library Outputs a value
4 Expression Language ${pageContext.request.requestURI} Outputs a value

Spring taglibs

Spring taglibs are a breeze to work with. Basically, Spring offers multiple ways to sanitize the output, each scope parameter having a possibility to be overridden by a narrower one:

  1. Application scoped, with the boolean defaultHtmlEscape context parameter
  2. Page scoped (i.e. all forms on page), with the tag
  3. Tag scoped, with the htmlEscape attribute of the tag

There’s only one catch; the  tag can take not only a code (the key in the property file) but also arguments – however, those are not escaped :

Hello, ${0} ${1}

A possible sanitization technique consists of the following steps:

  1. Create a new SanitizeMessageTag:
    • Inherit from Spring’s MessageTag
    • Override the relevant revolveArguments(Object) method
    • Use the desired sanitization technique (Spring uses its own HtmlUtils.htmlEscape(String))
  2. Copy the existing Spring TagLib Descriptor and create a new one out of it
  3. Update it to bind the message tag to the newly created SanitizeMessageTag class
  4. Last but not least, override the configuration of the taglib in the web deployment descriptor:

    By default, the JavaEE specifications mandates for the container to look for TLDs insides JARs located under the WEB-INF/lib directory. It is also possible to configure them in the web deployment descriptor. However, the configuration takes precedence over automatic scanning.

This way, existing JSP using the Spring taglib will automatically benefit from the new tag with no page-to-page update necessary.


The tag works the same way as the one, the only difference being there’s no global configuration parameter, only a escapeXml tag attribute which defaults to false.

The same technique as above can be used to default to true instead.


The EL syntax enables output outside any taglib so that the previous TLD override technique cannot be used to solve this.

Not known to many developers, EL snippets are governed by so-called EL resolvers. Standard application servers (including servlet containers like Tomcat) provide standard EL resolvers, but it is also possible to add others at runtime.

Note: though only a single EL resolver can be set in the JSP context, the resolver hierarchy implements the Composite pattern, so it’s not an issue.

Steps required to sanitize EL syntax by default are:

  1. Subclasses relevant necessary EL resolvers – those are ScopedAttributeELResolver, ImplicitObjectELResolver and BeanELResolver, since they may return strings
  2. For each, override the getValue() method:
    • Call super.getValue()
    • Check the return value
    • If it is a string, sanitize the value before returning it, otherwise, leave it as it is
  3. Create a ServletContextListener to register these new EL resolvers
    public class SanitizeELResolverListener implements ServletContextListener {
        public void contextInitialized(ServletContextEvent event) {
            ServletContext context = event.getServletContext();
            JspFactory jspFactory = JspFactory.getDefaultFactory();
            JspApplicationContext jspApplicationContext = jspFactory.getJspApplicationContext(context);
            ELResolver sber = new SanitizeBeanELResolver();
            // Register other EL resolvers


Trying to sanitize the output of an application after it has been developed is not the good way to raise developers concerns about security. However, dire situations require dire solutions. When the application has already been developed, the above approaches – one for taglibs, one for EL, show how to achieve this in a way that does not impact existing code and get the job done.

Categories: JavaEE Tags: , ,

Session Fixation and how to fix it

August 3rd, 2014 3 comments

These last few weeks, I’ve been tasked to fix a number of security holes in our software. Since I’m not a security expert, I’ve been extremely interested in this, and have learned quite a few things. Among them is the Session Fixation attack.

The context is an online Java application. One part is avalailable through simple HTTP, where you can do simple browsing;  when you enter credentials and successfully log in, you’re switched to HTTPS. This is a very common setup found online. For example, Amazon works this way: you browse the product catalog and put products in your basket in HTTP, but as soon as you login to checkout, you’re switched to HTTPS.

Now, the attack scenario is the following:

  1. Alice visits this online application and gets the value of the JSESSIONID cookie returned by the server
  2. Alice crafts a link to the application, including the previous JSESSIONID
  3. Alice sends the link to Bob
  4. Bob clicks on the link sent (rather stupidly, I’d say) or copies the link to his browser (the result is the same)
  5. In the same session, Bob enters his credentials to enter the secured part of the application. He’s now authentified within the session referenced by the JSESSIONID sent by Alice
  6. Using the JSESSIONID sent in her own browser, Alice is able to operate the application with the same credentials as Bob

Wow! If the site is an online banking site, this is extremely serious, giving potential attackers access to your bank account. This issue is known as Session Fixation and is referenced by OWASP.

Though we can require users not to click on links sent by emails, that’s a request for “aware” users, not everyone’s grandmother. We definitely need a more robust solution. The proposed remediation is quite easy to design: when the user switches from HTTP to HTTPS, he’s sent another JSESSIONID. Basically, his old session is destroyed, and a new one is created with all attributes of his former session.

It is possible to implement this behavior. However, if one is using Spring Security, it’s available out of the box through the SessionFixationProtectionStrategy class. Just plug it into the UserNamePasswordAuthenticationFilter.


Beware, most examples available on the Web only show usage of the strategy for session management!

Better yet, using JavaConfig and the WebSecurityConfigurerAdapter, it is configured out-of-the-box. Here’s an example of such configuration, with the strategy already configured:

public class SecurityConfig extends WebSecurityConfigurerAdapter {

    protected void configure(AuthenticationManagerBuilder amb) throws Exception {
        // Creates a simple principal in memory

    protected void configure(HttpSecurity http) throws Exception {
             // Requires user to have USER role
            // Requires channel to be HTTPS
            // Dont forget a simple form login!

Get the sample project – it is also a good template project for Spring MVC & Spring Security with JavaConfig, and check the JSESSIONID cookie value changed.

Note: you’ll need a SSL-enabled servlet container.

Categories: Java Tags: ,

Spring configuration modularization for Integration Testing

July 27th, 2014 1 comment

Object-Oriented Programming advocates for modularization in order to build small and reusable components. There are however other reasons for this. In the case of the Spring framework, modularization enables Integration Testing, the ability to test the system or parts of it, including assembly configuration.

Why is it so important to test the system assembled with the final configuration? Let’s take a simple example, the making of a car. Unit Testing the car would be akin to testing every nuts and bolts of the car separately, while Integration Testing the car would be like driving it on a circuit. By testing only the car’s components separately, selling the assembled car is a huge risk as nothing guarantees it will behave correctly in real-life conditions.

Now that we have asserted Integration Testing is necessary to guarantee the adequate level of internal quality, it’s time to enable Integration Testing with the Spring framework. Integration Testing is based on the notion of SUT. Defining the SUT is to define the boundaries between what is tested and its dependencies. In nearly all cases, test setup will require to provide some kind of test double for each required dependency. Configuring those test doubles can only be achieved by modularizing Spring configuration, so that they can replace dependent beans located outside the SUT.

Sample bean dependency diagram

Fig. 1 – Sample bean dependency diagram

Spring’s DI configuration comes in 3 different flavors: XML – the legacy way, autowiring and the newest JavaConfig. We’ll have a look at how modularization can be achieved for each flavor. Mixed DI modularization can be deduced from each separate entry.


Autowiring is an easy way to assemble Spring applications. It is achieved through the use of either @Autowiring or @Inject. Let’s cover quickly autowiring: as injection is implicit, there’s no easy way to modularize configuration. Applications using autowiring will just have to migrate to another DI flavor to allow for Integration Testing.


XML is the legacy way to inject dependencies, but is still in use. Consider the following monolithic XML configuration file:


At this point, Integration Testing orderService is not easy as it should be. In particular, we need to:

  • Download the application server
  • Configure the server for the jdbc/MyDataSource data source
  • Deploy all classes to the server
  • Start the server
  • Stop the server After the test(s)

Of course, all previous tasks have to be automated! Though not impossible thanks to tools such as Arquillian, it’s contrary to the KISS principle. To overcome this problem and make our life (as well as test maintenance) easier in the process requires tooling and design. On the tooling part, we’ll be using a local database. Usually, such a database is of the in-memory kind e.g. H2. On the design part, his requires separating our beans by creating two different configuration fragments, one solely dedicated to the data source to be faked and the other one for the beans constituting the SUT.

Then, we’ll use a Maven classpath trick: Maven puts the test classpath in front of the main classpath when executing tests. This way, files found in the test classpath will “override” similarly-named files in the main classpath. Let’s create two configuration files fragments:

  • The “real” JNDI datasource as in the monolithic configuration
  • The Fake datasource

    Note we are using a Tomcat datasource object, this requires the org.apache.tomcat:tomcat-jdbc:jar library on the test classpath. Also note the maxActive property. This reflects the maximum number of connections to the database. It is advised to always set it to 1 for test scenarios so that connections pool exhaustion bugs can be checked as early as possible.

The final layout is the following:

Fig. 2 – Project structure for Spring XML configuration Integration Testing

  1. JNDI datasource
  2. Other beans
  3. Fake datasource

The final main-config.xml file looks like:


Such a structure is the basics to enable Integration Testing.


JavaConfig is the most recent way to configure Spring applications, bringing both compile-time (as autowiring) and explicit configuration (as XML) safety.

The above datasources fragments can be “translated” in Java as follows:

  • The “real” JNDI datasource as in the monolithic configuration
    public class DataSourceConfig {
        public DataSource dataSource() throws Exception {
            Context ctx = new InitialContext();
            return (DataSource) ctx.lookup("jdbc/MyDataSource");
  • The Fake datasource
    public class FakeDataSourceConfig {
        public DataSource dataSource() {
            org.apache.tomcat.jdbc.pool.DataSource dataSource = new org.apache.tomcat.jdbc.pool.DataSource();
            return dataSource;

However, there are two problems that appear when using JavaConfig.

  1. It’s not possible to use the same classpath trick with an import as with XML previously, as Java forbids to have 2 (or more) classes with the same qualified name loaded by the same classloader (which is the case with Maven). Therefore, JavaConfig configuration fragments shouldn’t explicitly import other fragments but should leave the fragment assembly responsibility to their users (application or tests) so that names can be different, e.g.:
    @ContextConfiguration(classes = {MainConfig.class, FakeDataSource.class})
    public class SimpleDataSourceIntegrationTest extends AbstractTestNGSpringContextTests {
        public void should_check_something_useful() {
            // Test goes there
  2. The main configuration fragment uses the datasource bean from the other configuration fragment. This mandates for the former to have a reference on the latter. This is obtained by using the @Autowired annotation (one of the few relevant usage of it).
    public class MainConfig {
        private DataSource dataSource;
        // Other beans go there. They can use dataSource!


In this article, I showed how Integration Testing to a Fake data source could be achieved by modularizing the monolithic Spring configuration into different configuration fragments, either XML or JavaConfig.

However, the realm of Integration Testing – with Spring or without, is vast. Should you want to go further, I’ll hold a talk on Integration Testing at Agile Tour London on Oct. 24th and at Java Days Kiev on Oct. 17th-18th.

This article is an abridged version of a part of the Spring chapter of Integration Testing from the Trenches. Have a look at it, there’s even a sample free chapter!

Integration Testing from the Trenches

Categories: Java Tags: ,

Choosing a password manager

July 20th, 2014 2 comments

I’ve been thinking about having a more secure password management since ages. At first, my only concern was to share my bookmarks and history between my different computers (at that time, phones were conveniently left out of my scope). Since Firefox was my browser of choice, I decided to go for Foxmarks (now called XMarks and available for more browsers).

However, it soon became apparent that my natural lazyness came back and I synchronized my passwords too… in the cloud. After Firefox brought out-of-the-box synchronization through Sync, I continued to use the feature, not listening to the little voice in my head telling me it was a big security problem. I mean, Mozilla could secure the storage the way it wanted, I still felt not really safe… but lazyness prevailed. It was not until I had to change the way I synchronized stuff thanks to Firefox new Sync feature that I decided it was more than enough: I searched for a better way for my passwords to be available on all my devices.

The heart of the matter of choosing a good password is the following: I want my passwords to be easy to remember and easy to type while at the same time I want them to be impossible to either guess or crack. Usability versus security. This is somewhat summarized in this xkcd comis:

Password Strength

Some online service providers (such as Google and Dropbox) offer an interesting feature to defeat the natural tendency of users to choose easy-to-guess passwords, 2-steps authentication. This means you not only have to enter the password, you also have to provide another mean of authentication. Both previous providers use a code generated from some parameters known by both parties (provider and customer) but also time, so that guessing the code is only possible during a short amount of time (generally a minute). Another form of 2nd step is offered by banks as they send a code on your phone while you make an online transaction with your credit card, and then you have to enter it on the site to prove you’re the cardholder.

Some other providers even delegate authentication to third-party providers such as Google (always it) or Github. A well known process to do that is OAuth2. OAuth2 could solve the many passwords problem if all service providers would offer delegation. Unfortunately, most of them prefer to do authentication on their own (as well as keep identities their own, but that’s a story for another day). Even more unfortunate is the fact that they only offer traditional login/password authentication challenges. Back to square one…

Of course, I could make an effort to create a single hard-to-crack password… but with so many applications around, this is completely out of the question (or even impossible) to craft such a password for each one. None will advise to use the same password for all applications – as a hacker discovering the password on a site will be able to access all of them, but some advocate to prepend or append the domain name to the password. Alas, any simple automatic rule can easily be defeated by the means of automation cracking on the other side, so this should never ever been done – if you value the security of your accounts.

The answer is very simple: for each application, create a dedicated hard-to-crack and impossible-to-remember password and store them somewhere safe. This place of safety can then be secured with a a-little-easier-to-crack and possible-to-remember master password – the key to the Holy Grail. In essence, this describes a solution known as a password manager. I had a couple of requirements for such a software:

  • Open Source: I prefer having an Open Source solution when possible as I think that qualified people can (at least in theory) perform a security audit on it. A closed source solution means security through obfuscation and this just doesn’t work against real threats.
  • Multi-devices: yes, I’m one of those people that not only have multiple computers (office, desktop, laptop) with different Operating Systems (Windows and OSX) but also 2 phones and a tablet. So I want a solution that is compatible with all of those.
  • Configurable authentication: this requirement is very important as it not only let me choose how to authenticate into the store (e.g. password or key) but also increases the security of the solution.
  • Best practices: last but not least, I require security best practices to be implemented, such as hashing, salting, a slow hashing algorithm, etc.

Having chosen my password manager, now comes the hard part: should I keep my password store on a USB key I always keep by me (and a copy in a secure location, just to be sure), on my laptop I carry everywhere or in the cloud? This amounts to the same problem as before, security or usability? I’ve decided to store it the cloud, on a provider infrastructure secured by 2-steps authentication. I’ve also ensured that this store is made avalaible on my different devices, though I’m not unaware that a chain is as strong as its weakest link. With my current setup, I’m not sure I’m completely free of any prying effort by 3 letters agencies, or more precisely I’m sure I’m not. However, I believe I’ve increased my robustness to online intrusion by several degrees of magnitude and that should prevent script kiddies to play some nasty tricks on me. Your turn, now…

Categories: Technical Tags:

Easier Spring version management

July 6th, 2014 No comments

Earlier on, Spring migrated from a monolithic approach – the whole framework, to a modular one – bean, context, test, etc. so that one could decide to use only the required modules. This modularity came at a cost, however: in the Maven build configuration (or the Gradle one for that matter), one had to specify the version for each used module.


Of course, professional Maven users would improve this POM with the following:


There’s an more concise way to achieve the same through a BOM-typed POM (see section on scope import) since version 3.2.6 though.


Note that Spring’s BOM only sets version but not scope, this has to be done in each user POM.

Spring released very recently the Spring IO platform which also includes a BOM. This BOM not only includes Spring dependencies but also other third-party libraries.


There’s one single problem with Spring IO platform’s BOM, there’s no simple mapping from the BOM version to declared dependencies versions. For example, the BOM’s 1.0.0.RELEASE maps to Spring 4.0.5.RELEASE.

To go further:

Categories: Java Tags: ,