The Awnry Bear

You've got your app setup and integrated so that it can display a Google Maps MapView or SupportMapFragment (or whatever other map component that you've chosen) using the Google Maps Android API v2 via Google Play services. Great.

Now you want to display TileOverlays on top of your map. Maybe you want to tie into OpenWeatherMap's map layers service to display the current radar precipitation images on your map. So you configure your TileOverlay with an UrlTileProvider and point it at OWM's tile server endpoint, supplying the x, y, and zoom parameters. It all works great.

But the tiles show up as opaque. They block out everything behind them. The big storm rolling into town is obscuring the town's name. So let's just change the opacity from 100% to something like 75%. Easy to do using the Google Maps JavaScript API; should be easy to do in the Android API.

Except changing the opacity of TileOverlays isn't currently supported. You've got two options; you can setup your own tile server and change the opacity there, then simply point your UrlTileProvider to your server rather than OWM's, or you can do it on the Android device itself. I chose to do it on the device because my app receives hundreds of thousands of hits already, and images are big bandwidth, and honestly having to do image manipulation and caching and all that gave me a headache just thinking about it.

So the first thing we have to do is write a custom TileProvider implementation; unfortunately, the UrlTileProvider.getTile() method is marked final. (Not sure why; dumb design call if you ask me.) So that means our custom TileProvider has to not only change the opacity of the tile image, but it first has to fetch it too. Because some Google engineer didn't have the foresight to not make the UrlTileProvider's getTile() method not final and therefore hindering any reuse of the tried, true, and tested code of that class. Thanks Google. (Technically, you could wrap a UrlTileProvider in our custom implementation's getTile() method to do the dirty work of fetching the tile image; it worked, I tried that initially, but decided to just do the heavy lifting myself for performance reasons.)

Anyway, the following is a simple TileProvider that we can plugin to accomplish all of this:

/** * A custom {@link TileProvider} implementation that does what the {@link UrlTileProvider} does except it lets us * change the opacity of the tile images that are retrieved. * * In an ideal world, the {@link UrlTileProvider#getTile(int,int,int) UrlTileProvider.getTile()} method wouldn't be * marked as <code>final</code>, and we could've simply extended that class instead of rewriting the wheel. Until * Google fixes that little mistake, we're stuck with fetching the tile images as well as changing their opacity. * * <p>This code is public domain; use freely, but at your own risk.</p> * * @author Jonathon Freeman <[email protected]> * */ public class TranslucentUrlTileProvider implements TileProvider { private String url; private Paint opacityPaint = new Paint(); /** * This constructor assumes the <code>url</code> parameter contains three placeholders for the x- and y-positions of * the tile as well as the zoom level of the tile. The placeholders are assumed to be <code>{x}</code>, * <code>{y}</code>, and <code>{zoom}</code>. An example * for an OpenWeatherMap URL would be: http://tile.openweathermap.org/map/precipitation/{zoom}/{x}/{y}.png * * @param url The tile server's endpoint URL, from which to retrieve {@link Tile} images */ public TranslucentUrlTileProvider(String url) { this.url = url; setOpacity(75); } /** * Sets the desired opacity of map {@link Tile}s, as a percentage where 0% is invisible and 100% is completely opaque. * @param opacity The desired opacity of map {@link Tile}s (as a percentage between 0 and 100, inclusive) */ public void setOpacity(int opacity) { int alpha = (int)Math.round(opacity * 2.55); // 2.55 = 255 * 0.01 opacityPaint.setAlpha(alpha); } @Override public Tile getTile(int x, int y, int zoom) { URL tileUrl = getTileUrl(x, y, zoom); Tile tile = null; ByteArrayOutputStream stream = null; try { Bitmap image = BitmapFactory.decodeStream(tileUrl.openConnection().getInputStream()); image = adjustOpacity(image); stream = new ByteArrayOutputStream(); image.compress(Bitmap.CompressFormat.PNG, 100, stream); byte[] byteArray = stream.toByteArray(); tile = new Tile(256, 256, byteArray); } catch(IOException e) { e.printStackTrace(); } finally { if(stream != null) { try { stream.close(); } catch(IOException e) {} } } return tile; } /** * Helper method that returns the {@link URL} of the tile image for the given x/y/zoom location. * * <p>This method assumes the URL string provided in the constructor contains three placeholders for the x- * and y-positions as well as the zoom level of the desired tile; <code>{x}</code>, <code>{y}</code>, and * <code>{zoom}</code>. An example for an OpenWeatherMap URL would be: * http://tile.openweathermap.org/map/precipitation/{zoom}/{x}/{y}.png</p> * * @param x The x-position of the tile * @param y The y-position of the tile * @param zoom The zoom level of the tile * * @return The {@link URL} of the desired tile image */ private URL getTileUrl(int x, int y, int zoom) { String tileUrl = url .replace("{x}", Integer.toString(x)) .replace("{y}", Integer.toString(y)) .replace("{zoom}", Integer.toString(zoom)); try { return new URL(tileUrl); } catch(MalformedURLException e) { throw new AssertionError(e); } } /** * Helper method that adjusts the given {@link Bitmap}'s opacity to the opacity previously set via * {@link #setOpacity(int)}. Stolen from Elysium's comment at StackOverflow. * * @param bitmap The {@link Bitmap} whose opacity to adjust * @return A new {@link Bitmap} with an adjusted opacity * * @see http://stackoverflow.com/questions/14322236/making-tileoverlays-transparent#comment19934097_14329560 */ private Bitmap adjustOpacity(Bitmap bitmap) { Bitmap adjustedBitmap = Bitmap.createBitmap(256, 256, Bitmap.Config.ARGB_8888); Canvas canvas = new Canvas(adjustedBitmap); canvas.drawBitmap(bitmap, 0, 0, opacityPaint); return adjustedBitmap; }

This was just a quick hack of a class; there is plenty of room for improvement. For example, I'm not sure the Bitmap to byte array stuff is solid or even the best optimization of that kind of conversion. Also, the tile image dimensions are hardcoded at 256 pixels, which is what Google Maps expects and what OWM serves. In my own code I've refactored to fix these shortcomings and make the class more flexible, and I encourage you to do the same and change whatever else to meet your own needs.

I came across this article today, and I had to put in my two cents. Ultimately, I'm right, and you're wrong. ;)

1. Two lines of code is too many.

If a method has a second line of code, it is a code smell. Refactor.

Wrong. A method should be the smallest unit of functional logic, not something restricted to an arbitrary number of lines.

2. If it's not native, it's not really programming

By definition, a program is an entity that is run by the computer. It talks directly to the CPU and the OS. Code that does not talk directly to the CPU and the OS, but is instead run by some other program that does talk directly to the CPU and the OS, is not a program; it's a script.

Wrong. Just because a piece of code can be compiled to native binary is of little relevance. For example... Java, typically interpreted by a Java virtual machine, can be compiled to native code. Also, there are hardware CPUs available that natively run Java bytecode (notably the ones that come with Sun servers).

Ultimately, a programming language is a HUMAN language. How that human language is transformed into machine language has no bearing on whether the language is categorized as "programming" or "scripting". I would argue that intent and purpose is far greater an indicator of scripting vs. programming than language ever could be.

3. The "While" construct should be removed from all programming languages.

You can easily replicate While using "Repeat" and a boolean flag, and I just don't believe that it's useful to have the two structures. In fact, I think that having both "Repeat...Until" and "While..EndWhile" in a language confuses new programmers.

The kind of programmer who believes this is the same kind of programmer who cannot see the utility of a "for-in" construct, and probably would prefer to bring "goto" back in the respectible programmer's arsenal.

4. Copy/Pasting is not an antipattern, it fact it helps with not making more bugs

My rule of thumb - typing only something that cannot be copy/pasted. If creating similar method, class, or file - copy existing one and change what's needed. (I am not talking about duplicating a code that should have been put into a single method).

Wrong. Copy/pasting is an anti-pattern and is generally bad practice because it promotes duplication of logic. Chances are if you're copying and pasting more often than not, then you've got oodles of duplicate logic; you'll constantly find yourself with bugs as you try to juggle debugging issues in parallel. Utilize templates, inheritance, composition, and other effective techniques, where it makes sense, to reduce the amount of "similar" code you have.

5. Developing on .NET is not programming. Its just stitching together other people's code.

Having come from a coding background where you were required to know the hardware, and where this is still a vital requirements in my industry, I view high level languages as simply assembling someone else's work. Nothing essentially wrong with this, but is it 'programming'?

Wrong. You're standing on the shoulders of giants when programming in any language, including C, assembly, and--yes, even binary--because with all languages you are calling someone else's code at one point or another. Show me a C/C++ app that does not use libc. Show me a GUI app that does not invoke code provided by the windowing subsystem. Show me an assembly-written bootloader that does not invoke BIOS code. You get the point: unless you wrote the hardware routines that you're invoking, you're "stitching together other people's code" regardless of the language.

6. The use of try/catch exception handling is worse than the use of simple return codes and associated common messaging structures to ferry useful error messages.

Littering code with try/catch blocks is not a solution.

Just passing exceptions up the stack hoping whats above you will do the right thing or generate an informative error is not a solution.

Blindly passing exceptions up the stack is just as bad as blindly ignoring the return code in conventional error handling. Try/catch error handling is undoubtedly one of the best and most significant improvements made in software engineering in the last 20 years. Not only is it a cleaner, more graceful method of handling unexpected program behavior, but it also allows one to leverage polymorphic handling which IMO is just the cat's meow. Seriously, if you're arguing against try/catch just do the industry a favor and hang yourself now. Or become a used car salesman. Either way, lose the discipline because you're not suited.

7. Test Constantly

You have to write tests, and you have to write them FIRST. Writing tests changes the way you write your code. It makes you think about what you want it to actually do before you just jump in and write something that does everything except what you want it to do.

Correct! Test-driven development is another one of those big game-changers made in SE over the last 20 years. Usually derided by lazy programmers, writing code based on the functional requirements as defined by your test cases greatly improves your coverage and reduces the amount of code that needs to be written. Not to mention code confidence goes thru the roof. This is a no-brainer.

8. Object Oriented Programming is absolutely the worst thing that's ever happened to the field of software engineering.

The primary problem with OOP is the total lack of a rigorous definition that everyone can agree on. This easily leads to implementations that have logical holes in them, or language like Java that adhere to this bizarre religious dogma about what OOP means, while forcing the programmer into doing all these contortions and "design patterns" just to work around the limitations of a particular OOP system.

Wrong. OOP is one of the most brilliant concepts ever to grace the field of SE. I would even argue it is the single most important advance of the field in the last 30 years.

Your argument that OOP is bad is based on the fact the semantics surrounding it aren't concrete and implementations vary between vendors? Really?? I can guarantee that this argument is made by programmers who have not truly grasped the concept, even though they may have learned the syntax. (They can shoot the gun, but still can't aim worth a damn so to speak.)

The "contortions" you speak of are more than likely misinterpretations of doing things the Right Way(tm). The fact you would lump in something as elegant as the Observer pattern as a "workaround" is testament to the fact you simply don't get OOP.

9. C (or C++) should be the first programming language

The first language should NOT be the easy one, it should be one that sets up the student's mind and prepare it for serious computer science.C is perfect for that, it forces students to think about memory and all the low level stuff, and at the same time they can learn how to structure their code (it has functions!)

C++ has the added advantage that it really sucks :) thus the students will understand why people had to come up with Java and C#.

Why this hard-on for "low level stuff"? I mean, why should practical development need to know about things like memory management, pointers, etc? That stuff isn't common to all types of software development. Moreover, I would argue this infrastructure/boilerplate crap gets in the way of true development.

What is common to all types of development are topics and concepts such as variables, functions, data structures, algorithms, problem solving, and critical thinking. These are the things a budding programmer should focus on. If you want to do low-level development, then by all means learn low-level fundamentals once you've mastered basic programming principles. Trying to do both simultaneously for a newbie is a frustrating recipe for being overwhelmed and possibly turned off from the art altogether.

10. Classes should fit on the screen.

If you have to use the scroll bar to see all of your class, your class is too big.

Code folding and miniature fonts are cheating.

Mostly wrong. Arbitrary rule is arbitrary. Sure, it's good practice to keep classes well-defined, simple, and specific in their focus or purpose, but that does not imply a maximum LOC quota. A class that is several hundred LOC that performs lots of different, unrelated functions is definitely an outright code smell. But as long as the class is uniform in its purpose/focus and cannot be sensibly broken down into smaller logical components then its length is not an issue.

11. Making invisible characters syntactically significant in python was a bad idea

It's distracting, causes lots of subtle bugs for novices and, in my opinion, wasn't really needed. About the only code I've ever seen that didn't voluntarily follow some sort of decent formatting guide was from first-year CS students. And even if code doesn't follow "nice" standards, there are plenty of tools out there to coerce it into a more pleasing shape.

Real developers don't use Python. :P (Only kidding! I never learned Python, so I can't say.)

12. Singletons are not evil

There is a place for singletons in the real world, and methods to get around them (i.e. monostate pattern) are simply singletons in disguise. For instance, a Logger is a perfect candidate for a singleton. Additionally, so is a message pump. My current app uses distributed computing, and different objects need to be able to send appropriate messages. There should only be one message pump, and everyone should be able to access it. The alternative is passing an object to my message pump everywhere it might be needed and hoping that a new developer doesn't new one up without thinking and wonder why his messages are going nowhere. The uniqueness of the singleton is the most important part, not its availability. The singleton has its place in the world.

Let's say you've got your Spring Security 3 application working. You can login. You've got a RememberMeServices set up, so users don't have to login each time they visit your site. But you're having trouble getting the logout functionality to work, or maybe you just need to define some custom functionality to be called when the user logs out. What you need is a custom LogoutHandler.

If you have a <logout> element defined in your <http> namespace element, go ahead and get rid of that since we will be manually configuring what <logout> does for you.

Configure a LogoutFilter

First, let's configure our LogoutFilter:

<beans:bean id="logoutFilter" class="org.springframework.security.web.authentication.logout.LogoutFilter"> <beans:constructor-arg index="0" value="/login" /> <beans:constructor-arg index="1"> <beans:list> <beans:ref bean="rememberMeServices" /> <beans:bean id="securityContextLogoutHandler" class="org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler" /> </beans:list> </beans:constructor-arg> <beans:property name="filterProcessesUrl" value="/logout" /> </beans:bean>

One of the great things about Spring Security is that it provides lots of classes right out of the box that we can simply configure. No custom coding is necessary (not now, at least).

As you can see, we're just defining a LogoutFilter and setting two constructor arguments, and one property. The first argument is the URL to redirect to after logging the user out. Use whatever you want here; for our example, I'm redirecting the user to the login page.

The second argument is a variable-length list of LogoutHandler implementations, i.e. classes that implement the LogoutHandler interface. I have a RememberMeServices, so I have that included. I also want my user's session invalidated, so I've also included a SecurityContextLogoutHandler. According to the Spring documentation, it is recommended to have your RememberMeServices called first and then the SecurityContextLogoutHandler. The RememberMeServices takes care of removing the remember me stuff (cookie, database entries, etc.), and the SecurityContextLogoutHandler handles invalidating the user's session.

The property we are setting is the filterProcessesUrl which tells Spring Security on which URL to "monitor". I've set it to /logout, so when a user hits that URL the LogoutFilter will be called.

The next thing to do is to tell Spring Security that we want our LogoutFilter included in the filter chain. There are two ways to do this. The first way is if you are using a <http> element, in which case you will need to add <custom-filter> like this:

<http use-expressions="true" auto-config="false" entry-point-ref="loginUrlAuthenticationEntryPoint"> ... <custom-filter position="LOGOUT_FILTER" ref="logoutFilter" /> </http>

If you are not using the <http> element and instead are just using standard beans, you'll need to add the <custom-filter> to the LogoutFilter bean configuration:

<beans:bean id="logoutFilter" class="org.springframework.security.web.authentication.logout.LogoutFilter"> <beans:constructor-arg index="0" value="/login" /> <beans:constructor-arg index="1"> <beans:list> <beans:ref bean="rememberMeServices" /> <beans:bean id="securityContextLogoutHandler" class="org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler" /> </beans:list> </beans:constructor-arg> <beans:property name="filterProcessesUrl" value="/logout" /> <custom-filter position="LOGOUT_FILTER"/> </beans:bean>

So now that we've got a LogoutFilter configured, we should be able to click a logout link and have the user's rememberMe cookie removed along with any corresponding database records, as well as have the user's session invalidated.

Custom LogoutHandler

That's all good and well, you say, but I need some custom functionality to be invoked when the user logs out. Luckily, that is the easiest part of this entire post.

First, create a LogoutHandler implementation:

public class MyLogoutHandler implements LogoutHandler { public void logout(HttpServletRequest request, HttpServletResponse response, Authentication authentication) { // Do whatever you want here. } }

The next thing to do is add the custom LogoutHandler to our LogoutFilter we defined earlier:

<beans:bean id="logoutFilter" class="org.springframework.security.web.authentication.logout.LogoutFilter"> <beans:constructor-arg index="0" value="/account/login" /> <beans:constructor-arg index="1"> <beans:list> <beans:ref bean="rememberMeServices" /> <beans:bean id="securityContextLogoutHandler" class="org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler" /> <beans:bean id="myLogoutHandler" class="com.awnry.springexample.MyLogoutHandler" /> </beans:list> </beans:constructor-arg> <beans:property name="filterProcessesUrl" value="/account/logout" /> </beans:bean>

So you need a control that allows users to select multiple items for a given field.

The obvious choice, an HTML multiple option select box, is not user-friendly. It isn't apparent to most users that you can make multiple selections, or exactly how multiple selections can be made.

Unfortunately, jQuery UI does not come packaged with a picklist widget. What's more is there really aren't any good, current 3rd-party implementations either.

jquery-ui-picklist

Enter the jquery-ui-picklist widget.

Usage couldn't be simpler. Let's say you have a user-unfriendly multiple option select box:

<select id="items" name="items" multiple="multiple"> <option value="1">Option 1</option> <option value="2" selected="selected">Option 2</option> <option value="3">Option 3</option> <option value="4" selected="selected">Option 4</option> <option value="5">Option 5</option> </select>

To make it a picklist, simply:

$(function() { $("#items").pickList(); });

And you'll get something like this:

Users can manage their selections by choosing the item(s) in the appropriate pane, and using the control buttons to add or remove them. Multiple items can be selected simultaneously as expected with Ctrl + click, and a range of items can be selected as expected with Shift + click.

So you've got your Spring Security-enabled application up and running. You can login, logout, and you're even authorizing based on roles and permissions. You're glad to progress past all that boring infrastructure coding and get onto the meat and potatoes of your application: the business logic. You crank out controller after controller, and life is great because you're using Spring MVC.

But then you begin needing to access the currently logged in user from your Web controllers. So you do something like this:

@Controller public class MyAwesomeController { @RequestMapping(value="/foo/bar", method=RequestMethod.GET) public String foobar() { User activeUser = (User)SecurityContextHolder.getContext().getAuthentication().getPrincipal(); System.out.println("Currently logged in user is: " + activeUser.getFullName()); ... return "foo/bar"; } }

Since you're using your User domain object as your UserDetails implementation, this works out kind of nice. You're able to get your user by getting the principal. Peachy.

Of course, the first time you did this you grumbled, and even though you knew polluting your controllers with infrastructure was the Wrong Way™ you did it anyway thinking, "Hey, it's only a single line, and it's just this one time."

But now you're on the 6th or 7th iteration of this bad coding practice, and you feel it's time for a change. Or a cold shower. Or both.

The Common Way

First, let's take a look at the obvious "solution". I say "solution" because really it doesn't solve the problem of polluting your controller layer with your security layer.

@Controller public class MyAwesomeController { @RequestMapping(value="/foo/bar", method=RequestMethod.GET) public String foobar(Principal principal) { User activeUser = (User)((Authentication) principal).getPrincipal(); System.out.println("Currently logged in user is: " + activeUser.getFullName()); ... return "foo/bar"; } }

This method isn't so terrible because at least now Spring is injecting the principal into the method for you. It's still pretty darn nasty because you're still polluting your controller.

A Better Approach

Here's a much better approach:

@Controller public class MyAwesomeController { @Autowired ActiveUserAccessor activeUserAccessor; @RequestMapping(value="/foo/bar", method=RequestMethod.GET) public String foobar() { User activeUser = activeUserAccessor.getActiveUser(); System.out.println("Currently logged in user is: " + activeUser.getFullName()); ... return "foo/bar"; } }

Then you have the interface:

public interface ActiveUserAccessor { public User getActiveUser(); }

Then you have an implementation:

@Component("activeUserAccessor") public class ActiveUserAccessorImpl implements ActiveUserAccessor { public User getActiveUser() { return (User)SecurityContextHolder.getContext().getAuthentication().getPrincipal(); } }

But all we've done is move the original stuff into a utility class, you sneer. (Jeez, calm down... you're way too testy.)

At first glance, yes. We're still having to call a line of infrastructure code from our controller, but we now have the benefit of being able to swap out a different implementation of our ActiveUserAccessor at runtime. This is very useful for testing, or if we later decide to abandon Spring Security in favor of another authentication framework. What's important is that we've decoupled Spring Security from our application, and that's a Good Thing™.

The Best Way™

That's all good and well, you scoff, but we want something better. It sure would be nice not to have to call even a single line of infrastructure code from our controller. If only Spring would just inject our User into the controller. So let's try that:

@Controller public class MyAwesomeController { @RequestMapping(value="/foo/bar", method=RequestMethod.GET) public String foobar(@ActiveUser User activeUser) { System.out.println("Currently logged in user is: " + activeUser.getFullName()); ... return "foo/bar"; } }

I'm going to wait for you to finish clapping and cheering my name. ... Okay, so that's pretty awesome right? Let's find out how to make it work.

First, we need to create the custom @ActiveUser annotation:

@Target(ElementType.PARAMETER) @Retention(RententionPolicy.RUNTIME) @Documented public @interface ActiveUser {}

Then, we need to provide a WebArgumentResolver implementation to resolve the parameter:

public class ActiveUserWebArgumentResolver implements WebArgumentResolver { public Object resolveArgument(MethodParameter methodParameter, NativeWebRequest webRequest) { Annotation[] annotations = methodParameter.getParameterAnnotations(); if(methodParameter.getParameterType().equals(User.class)) { for(Annotation annotation : annotations) { if(ActiveUser.class.isInstance(annotation)) { Principal principal = webRequest.getUserPrincipal(); return (User)((Authentication) principal).getPrincipal(); } } } return WebArgumentResolver.UNRESOLVED; } }

The resolver essentially ensures that any method parameter that's annotated with our @ActiveUser is in fact a User object. If it is, it returns the principal which is, in our case, the currently logged in User.

Finally, to wrap it all together, the resolver's bean configuration:

<!-- Enables our custom @ActiveUser annotation. --> <bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter"> <property name="customArgumentResolver" ref="activeUserResolver" /> </bean> <bean id="activeUserResolver" class="com.awnry.springexample.ActiveUserWebArgumentResolver" />

First off, what exactly does "two-factor authentication" mean? Two-factor authentication simply adds a second credential in addition to the username (and besides the password) on which to authenticate. For example, in addition to a username to couple with a password, you may require the user to enter their corporate domain, client name, or state.

If you're just getting started with Spring Security, you probably have realized how steep of a learning curve there is. Even if you understand the high-level architecture, making things fit together and getting that combination just right can be a frustrating experience. So in this article, I'm going to show you how to get two-factor authentication working with a Spring web application.

"Single-Factor" Authentication with Spring Security

Let's look at the configuration for "single-factor" authentication, i.e. username and password. We're going to go with a combination of using the namespace and using straight beans.

<beans:beans xmlns="http://www.springframework.org/schema/security" xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd"> <http use-expressions="true" auto-config="false" entry-point-ref="loginUrlAuthenticationEntryPoint"> <intercept-url pattern="/secured" access="isAuthenticated()" /> <intercept-url pattern="/**" access="permitAll" /> <custom-filter position="FORM_LOGIN_FILTER" ref="usernamePasswordAuthenticationFilter" /> <logout logout-url="/logout" /> </http> <authentication-manager alias="authenticationManager"> <authentication-provider ref="authenticationProvider" /> </authentication-manager> <beans:bean id="authenticationProvider" class="org.springframework.security.authentication.dao.DaoAuthenticationProvider"> <beans:property name="passwordEncoder"> <beans:bean class="org.springframework.security.authentication.encoding.ShaPasswordEncoder" /> </beans:property> <beans:property name="userDetailsService" ref="userService" /> </beans:bean> <beans:bean id="userService" class="com.awnry.springexample.UserDetailsServiceImpl" /> <beans:bean id="loginUrlAuthenticationEntryPoint" class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint"> <beans:property name="loginFormUrl" value="/login" /> </beans:bean> <beans:bean id="usernamePasswordAuthenticationFilter" class="org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter"> <beans:property name="authenticationManager" ref="authenticationManager" /> <beans:property name="authenticationFailureHandler" ref="failureHandler" /> <beans:property name="authenticationSuccessHandler" ref="successHandler" /> <beans:property name="filterProcessesUrl" value="/processLogin" /> <beans:property name="postOnly" value="true" /> </beans:bean> <beans:bean id="successHandler" class="org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler"> <beans:property name="defaultTargetUrl" value="/login" /> </beans:bean> <beans:bean id="failureHandler" class="org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler"> <beans:property name="defaultFailureUrl" value="/login?login_error=true" /> </beans:bean> </beans:beans>

There isn't much to explain here, especially if you're familar with using a namespace-beans hybrid approach to configuring Spring Security. The only class we have to provide here is a UserDetailsService implementation; here is a simple one for completeness sake:

@Service("userDetailsService") public class UserDetailsServiceImpl implements UserDetailsService { @Autowired private UserDao userDao; @Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException, DataAccessException { User User = userDao.findByUsername(username); System.out.println("Returning user: " + user); return user; } }

All our UserDetailsService does is return the User with the given username. The details of the DAO and how the retrieval is done is not important; what is important is that we have a UserDetailsService implementation that can be used with Spring's UsernamePasswordAuthenticationFilter.

Adding the Two-Factor Authentication Filter

So now that we have basic username/password authentication working, let's make the necessary changes to handle a second input field, such as the user's corporate domain.

The first thing we need to do is extend the UsernamePasswordAuthenticationFilter class so that it can handle a second input field.

/** * A custom {@link UsernamePasswordAuthenticationFilter} that adds two-factor authentication. * A user enters a username and an "extra" input along with a password, and the username and extra * input values are returned through the <code>obtainUsername()</code> method as a colon-delimited * string. The delimiter string (a colon by default) can be customized with the * <code>setDelimiter()</code> method. * * @author Jonathon Freeman */ public class TwoFactorAuthenticationFilter extends UsernamePasswordAuthenticationFilter { private String extraParameter = "extra"; private String delimiter = ":"; /** * Given an {@link HttpServletRequest}, this method extracts the username and the extra input * values and returns a combined username string of those values separated by the delimiter * string. * * @param request The {@link HttpServletRequest} containing the HTTP request variables from * which the username client domain values can be extracted */ @Override protected String obtainUsername(HttpServletRequest request) { String username = request.getParameter(getUsernameParameter()); String extraInput = request.getParameter(getExtraParameter()); String combinedUsername = username + getDelimiter() + extraInput; System.out.println("Combined username = " + combinedUsername); return combinedUsername; } /** * @return The parameter name which will be used to obtain the extra input from the login request */ public String getExtraParameter() { return this.extraParameter; } /** * @param extraParameter The parameter name which will be used to obtain the extra input from the login request */ public void setExtraParameter(String extraParameter) { this.extraParameter = extraParameter; } /** * @return The delimiter string used to separate the username and extra input values in the * string returned by <code>obtainUsername()</code> */ public String getDelimiter() { return this.delimiter; } /** * @param delimiter The delimiter string used to separate the username and extra input values in the * string returned by <code>obtainUsername()</code> */ public void setDelimiter(String delimiter) { this.delimiter = delimiter; } }

This class may look nasty, but it's really pretty simple. The real work is happening in the obtainUsername() method. What this method does is retrieve the username and "extra" input field from the HttpServletRequest object that's passed in. It then concatenates these two values into one string, separating them by the delimiter string (a colon, by default). It then returns this combined string. The parameter from which the "extra" input field is read is extra by default, but just like the delimiter string this parameter name can be customized which we will illustrate later.

Combining the username and the extra field into one string that is returned by the obtainUsername() method is a quick and simple way of reusing components that work with the single-factor authentication components provided by Spring. There are other ways we could acheive two-factor authentication, but this is one of the easiest ways.

Updating UserDetailsService

Now that we have created an authentication filter that supports two-factor authentication, we need to update the loadUserByUsername() method in our UserDetailsService implementation. The change needed involves extracting the username and the extra input field from the username string that is returned by our TwoFactorAuthenticationFilter's obtainUsername() method, so that we can query our list of users using both values. Here is our updated loadUserByUsername() method:

@Override public UserDetails loadUserByUsername(String input) throws UsernameNotFoundException, DataAccessException { String[] split = input.split(":"); if(split.length < 2) { System.out.println("User did not enter both username and corporate domain."); throw new UsernameNotFoundException("Must specify both username and corporate domain"); } String username = split[0]; String domain = split[1]; System.out.println("Username = " + username); System.out.println("Corporate domain = " + domain); User user = userDao.findByUsernameAndDomain(username, domain); if(user == null) { System.out.println("User could not be found, must be an invalid username/domain combo."); throw new UsernameNotFoundException("Invalid username or corporate domain"); } System.out.println("Returning user: " + user); return user; }

It's pretty straightforward. First, we split the given username into its two components: the username and the extra field. In this example, the extra field is the user's corporate domain. Once we have the username and the domain, we can use our DAO to find the matching user.

That's all the Java code necessary to implement two-factor authentication! Pretty simple, huh? The great thing about modifying these two classes is that the rest of the Spring Security components can work with them without being none the wiser, and we don't have to make lots of modifications to the configuration. Speaking of the configuration...

Tying It All Together

The last piece of the puzzle is to update our configuration to use our new TwoFactorAuthenticationFilter:

<beans:beans xmlns="http://www.springframework.org/schema/security" xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd"> <http use-expressions="true" auto-config="false" entry-point-ref="loginUrlAuthenticationEntryPoint"> <intercept-url pattern="/secured" access="isAuthenticated()" /> <intercept-url pattern="/**" access="permitAll" /> <custom-filter position="FORM_LOGIN_FILTER" ref="twoFactorAuthenticationFilter" /> <logout logout-url="/logout" /> </http> <authentication-manager alias="authenticationManager"> <authentication-provider ref="authenticationProvider" /> </authentication-manager> <beans:bean id="authenticationProvider" class="org.springframework.security.authentication.dao.DaoAuthenticationProvider"> <beans:property name="passwordEncoder"> <beans:bean class="org.springframework.security.authentication.encoding.ShaPasswordEncoder" /> </beans:property> <beans:property name="userDetailsService" ref="userService" /> </beans:bean> <beans:bean id="userService" class="com.awnry.springexample.UserDetailsServiceImpl" /> <beans:bean id="loginUrlAuthenticationEntryPoint" class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint"> <beans:property name="loginFormUrl" value="/login" /> </beans:bean> <beans:bean id="twoFactorAuthenticationFilter" class="com.awnry.springexample.TwoFactorAuthenticationFilter"> <beans:property name="authenticationManager" ref="authenticationManager" /> <beans:property name="authenticationFailureHandler" ref="failureHandler" /> <beans:property name="authenticationSuccessHandler" ref="successHandler" /> <beans:property name="filterProcessesUrl" value="/processLogin" /> <beans:property name="postOnly" value="true" /> <beans:property name="extraParameter" value="domain" /> </beans:bean> <beans:bean id="successHandler" class="org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler"> <beans:property name="defaultTargetUrl" value="/login" /> </beans:bean> <beans:bean id="failureHandler" class="org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler"> <beans:property name="defaultFailureUrl" value="/login?login_error=true" /> </beans:bean> </beans:beans>

There you have it. In the twoFactorAuthenticationFilter bean definition, we set the extraParameter property to "domain" which is the name of the input field to use in our login form. If we wanted, we could also customize the parameter names for the username and password fields as well as the delimiter string to something other than a colon. Remember if you decide to change the delimiter string, you'll need to update your UserDetailsService implementation since it has the colon hardwired in.

Over the last week I've been working to get Spring Security 3.0.7 integrated into a Web application I'm developing. One of the first things I did was set the URL for the login form page to /login. It's easy to do by setting the loginFormUrl on the LoginUrlAuthenticationEntryPoint if you're not using the namespace (namespace equivalent is the login-page attribute of the <form-login> tag).

The problem is that the URL that your login form POSTs to has to be different. The reason is, behind the scenes, the UsernamePasswordAuthenticationFilter handles the request. Even when you set the postOnly attribute to true, an exception is thrown (as if you had POSTed from a form) when you try to access the page with a simple GET.

Fortunately, the fix is fairly trivial. We simply must override the requiresAuthentication() method in the UsernamePasswordAuthenticationFilter class.

Overriding requiresAuthentication()

When a request is handed off to the UsernamePasswordAuthenticationFilter, the doFilter() method calls the requiresAuthentication() method to determine whether or not it needs to handle the request or if it needs to forward the request to the next guy in the filter chain. We are going to override the method to check which HTTP method was used to access the page; if it's GET, then we can safely ignore the request and let the next filter handle it.

Here is an example of overriding the method:

public class MyAuthenticationFilter extends UsernamePasswordAuthenticationFilter { @Override protected boolean requiresAuthentication(HttpServletRequest request, HttpServletResponse response) { if(request.getMethod().equals("POST")) { return super.requiresAuthentication(request, response); } else { return false; } } }

As you can tell, it's not doing a whole lot here. All our overriding method does is check the HTTP method type. If it's a POST, we yield to the UsernamePasswordAuthenticationFilter's logic to apply its rules (and probably handle the request). If it's anything other than a POST, such as GET, we return false. This will signal to the UsernamePasswordAuthenticationFilter's doFilter() method that it does not need to handle the request. It gets sent to the next guy in the filter chain and our login form will get called.

This way, we can have our custom login form located at, say, /login and yet we can still POST to /login to have the UsernamePasswordAuthenticationFilter invoked and the user authenticated.