Monthly Archives: June 2014

eclipse-pmd

eclipse-pmd – New PMD plugin for Eclipse

I am Eclipse user. So when I wanted to analyze my code by PMD, I needed to use “PMD for Eclipse” plugin. This plugin used to be very buggy, which was enhanced in later versions (currently 4.0.3). But the performance is really bad sometimes. Especially when you are dealing with relatively big codebase and have option “Check code after Saving” on.

ecplise-pmd plugin

So when I realized that there is new alternative PMD plugin called eclipse-pmd out there I evaluated it immediately with great happiness.

Installation uses modern Eclipse Marketplace method. You just need to go “Help” -> “Eclipse Marketplace…” and search for “eclipse-pmd”. Than hit “Install” and follow instructions.

After installation I was a little bit confused because I didn’t find any configuration options it general settings (“Window” -> “Preferences”). I discovered that you need to turn on PMD for each project separately. Which make sense, because you can have different rule set per project. So to turn it on, right click on project -> “Preferences” -> “PMD” (there would be two PMD sections if you didn’t uninstall old PMD plugin)-> “Enable PMD for this project” -> “Add…”. Now you should pick a location of PMD ruleset file.

pick-ruleset

Unlike old PMD plugin, eclipse-pmd don’t import ruleset. It is using ruleset file directly. This is very handy, because typically you want to have it in source control. When you pull changes to ruleset file from source control system, they are applied without re-import (re-import was needed for old PMD plugin).

Problem can be when you (or your team) don’t have existing ruleset. I would suggest to start with full ruleset and exclude rules you don’t want to use. Your ruleset would evolve anyway, so starting with most restrictive (default) deck make perfect sense for me. Unfortunately eclipse-pmd plugin doesn’t provide option to generate ruleset file. So I created full ruleset for PMD 5.1.1 (5.1.1 is PMD version not plugin version). I have to admit that it was created with help of old PMD plugin.

You can see that I literally included all the rule categories. I would suggest to specify your set this way and exclude/configure rules explicitly as needed. Here is link to PMD site that explains how to customize your ruleset. This approach can be handy when PMD version will be updated. New rules can appear in category and they will be automatically included into your ruleset when you are listing categories, not rules individually. But you have to keep eye on new rules/categories when updating PMD version anyway, because categories often change with new PMD version.

So now we should have rulset configured and working. Here are some screen shots of rules in action:

When you hover over left side panel warning:

eclipse-pmd

When you hover over problematic snippet:

eclipse-pmd

When you do quick fix on problematic snippet:

eclipse-pmd

Generating suppress warning annotation for PMD rules is very nice feature. It also provide quick fixes for some rules. Take a look at its change log site for full list.

These PMD warning sometimes clash with Eclipse native warnings, so there is possibility to make them more visible. Go to “Window” -> “Preferences” -> “General” -> “Editors” -> “Text Editors” -> “Annotations” and find “PMD Violations”.

eclipse-pmd

Here you can configure your own style of highlighting PMD issues. This is mine:

eclipse-pmd

To explore full feature list of this plugin take a look at its change log site.

There are some features in old plugin I miss though. For example I would appreciate some quick link or full description of the rule. Short description provided is sometimes not enough. I encourage you to take a look at full PMD rule description if you are not sure what’s source of the problem. You will learn a lot about Java language itself or about libraries you are using. Quick links would help a lot in such case.

Also some rules doesn’t use code highlighting (only side panel markers). It is sometimes hard to distinguish between compiler and PMD issues. This is problem for me because our team doesn’t use JavaDoc warnings but I do. So I get a lot of JavaDoc warnings from code written by teammates. And sometimes I can miss PMD issue because it is lost in JavaDoc warnings. (Fortunately SVN commit is rejected if I forget to fix some rule).

Conclusion

This plugin enhanced my Eclipse workflow. No more disruptions because of endless “Checking code…” processing by old plugin.

Spring Security Misconfiguration

I recently saw Mike Wienser’s SpringOne2GX talk about Application Security Pitfalls. It is very informative and worth watching if you are using Spring’s stack on servlet container.

It reminded me one serious Spring Security Misconfiguration I was facing once. Going to explain it on Spring’s Guide Project called Securing a Web Application. This project uses Spring Boot, Spring Integration and Spring MVC.

Project uses these views:

@Configuration
public class MvcConfig extends WebMvcConfigurerAdapter {
    
    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/home").setViewName("home");
        registry.addViewController("/").setViewName("home");
        registry.addViewController("/hello").setViewName("hello");
        registry.addViewController("/login").setViewName("login");
    }

}

Where “/home”, “/” and “/login” URLs should be publicly accessible and “/hello” should be accessible only to authenticated user. Here is original Spring Security configuration from Guide:

@Configuration
@EnableWebMvcSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/", "/home").permitAll()
                .anyRequest().authenticated();
        http
            .formLogin()
                .loginPage("/login")
                .permitAll()
                .and()
            .logout()
                .permitAll();
    }

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth
            .inMemoryAuthentication()
                .withUser("user").password("password").roles("USER");
    }
}

Nice and explanatory as all Spring’s Guides are. First “configure” method registers “/” and “home” as public and specifies that everything else should be authenticated. It also registers login URL. Second “configure” method specifies authentication method for role “USER”. Of course you don’t want to use it like this in production :).

Now I am going to slightly amend this code.

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        //!!! Don't use this example !!!
        http
            .authorizeRequests()              
                .antMatchers("/hello").hasRole("USER");
        
        //... same as above ...
    }

Everything is public and private endpoints have to be listed. You can see that my amended code have the same behavior as original. In fact it saved one line of code.

But there is serious problem with this. What if my I need to introduce new private endpoint? Let’s say I am not aware of the fact that it needs to be registered in Spring Security configuration. My new endpoint would be public. Such misconfiguration is really hard to catch and can lead to unwanted exposure of URLs.

So conclusion is: Always authenticate all endpoints by default.