public interface MemberService {
        @Nullable
	Member complicatedLookup(@NotNull ComplexArgument argument);
}

public class DefaultMemberService implements MemberService {
        @Nullable
        @Cacheable(modelId = "Member")
        public Member complicatedLookup(@NotNull ComplexArgument argument) {
                // some complex stuff
        }
}

This code works perfectly well: when you call the DefaultMemberService.complicatedLookup(...) method more than once with the same (read equal(Object)) ComplexArgument object, the caching framework intercepts the call in and only the first call will go to do the // some complex stuff.
The problem is when you return an object from a Hibernate DAO call and that object is enhanced by CGLIB. Now the cache has a reference to an object that references an invalid Session.
We found this when our integration tests worked fine on their own, but started failing when we ran them as part of our automatic build. The prospect of going through every possible code path to find out if there is a cached CGLIB-enhanced object was daunting. Luckily, Spring AOP was quick to rescue. We wrote a simple little aspect that checks that any method with the @Cacheable annotation does not return a CGLIB-enahanced object.

@Aspect
public class CacheManagerAspect {

    @AfterReturning(pointcut =
            "@annotation(org.springmodules.cache.annotations.Cacheable)",
                returning = "ret",
                argNames = "jp, ret")
    public void indicateLazilyLoaded(JoinPoint jp, Object ret) throws Exception {
        checkNotCGLIBEnhanced(jp, ret);
    }

    private void checkNotCGLIBEnhanced(JoinPoint jp, Object o)
        throws IllegalAccessException, InvocationTargetException {
        if (o == null) return;
        String name = o.getClass().getName();
        if (!name.startsWith("uk.co.package")) return;
        if (name.contains("$$Enhancer"))
                 throw new RuntimeException(
                        "You cannot cache a CGLIB-Enhanced object at " + jp);

        PropertyDescriptor[] descriptors =
                 BeanUtils.getPropertyDescriptors(o.getClass());
        for (PropertyDescriptor descriptor : descriptors) {
            Object value = descriptor.getReadMethod().invoke(o);
            checkNotCGLIBEnhanced(jp, value);
        }
    }

}

Simple, but powerful stuff from SpringModules and Spring AOP!

Here is a brief run down:

jQuery

• Event Handling is 103% Faster
• CSS Selectors are 13% faster
• .offset() is 21% faster
• .css() is 25% faster
• Exposed Speeds
• .toggle() can now accept more functions
• You can now unbind bound .toggle() and .one() functions
• .index() supports jQuery collections
• jQuery.makeArray can convert ANYTHING to an array.
• beforeSend can cancel Ajax calls
• Exposed Speeds

Ruby on Rails
Major New Features:

• Time zones
• Dirty tracking
• Gem Dependencies
• Named scope
• UTC-based migrations
• Better caching

Ryan Bates has produced some awesome screencasts on the above new features in rails. I highly recommend you check his Railscasts out.

SpringOne is being held at MetroPolis Business Center, MetroPolis Antwerp, Groenendaallaan 394 2030, Antwerp, Belgium. More information can be found here.

Jan will be presenting on Thursday 12th June at 14.00 - 15.00 and both he and I will be at the Conference for most of the two days. If you are attending the conference please let me know and we can arrange to meet up over a coffee/beer.

The organisers have put together a very interesting event, with speakers from SpringSource, Cake and UBS. Followed by interactive breakout sessions to chat with the speakers and other User Group members, this is a fantastic opportunity to learn, share your experience, broaden your network and join this community. Come join us and find out about the exciting new developments of the Spring framework and how practitioners are enabling their businesses, by using Spring as a core construct of their solutions.

Event Details What: London Spring User Group : First London Spring User Group Event
Where: The Crypt, St. James Church, Clerkenwell, EC1R
When: This Friday - 30 May 2008 Starts at 12:00

* Dave Syer of Spring Source will be telling us about Spring Batch
* Rob Purcell & Manoj Bajaj of UBS will give a talk on reliable database/messaging transactions without 2PC
* Jan Machacek of Cake will present a case study of a project at Central Government, where Spring was used successfully.

SpringSource, Skills Matter and Cake Solutions! are all sponsors of the event.

Please register here

I hope to see you there.

It will have some smooth UI tweaks thanks to jQuery and pretty interesting features on the contact page with integrated Google Maps.

The site is almost ready. Just a few odds and ends to tie up.

Once the site is launched I’ll blog a quick feature tour with some insights into the technologies used.

Let’s see how to enable this functionality with Acegi Security.

Firstly, add org.acegisecurity.concurrent.SessionRegistry implementation bean to your security context:

<bean id="sessionRegistry" class="org.acegisecurity.concurrent.SessionRegistryImpl" />

We are using default Acegi implementation org.acegisecurity.concurrent.SessionRegistryImpl.

Next, define the org.acegisecurity.concurrent.SessionController bean:

    <bean id="sessionController" class="org.acegisecurity.
           concurrent.ConcurrentSessionControllerImpl">
        <property name="exceptionIfMaximumExceeded" value="true"/>
        <property name="maximumSessions" value="1" />
        <property name="sessionRegistry" ref="sessionRegistry"/>
    </bean>

As you can see, it takes sessionRegistry property, as well as two additional properties maximumSessions and exceptionIfMAximumExceeded.
maximumSessions says how meny concurrent login sessions are allowed (in our case just one)
if exceptionIfMAximumExceeded property is set to true, exception will be thrown every time the user tries to login concurrently. You can check this exception in your login controller and display user with a message.
Otherwise, if exceptionIfMAximumExceeded property is set to false, exception will NOT be thrown. If user tries to login concurrently, he will be allowed, but his last login session (before the concurrent one) will be invalidated.

Last step is to add sessionController property to your ProviderManager bean:

     <bean id="authenticationManager" class="org.acegisecurity.providers.ProviderManager">
		<property name="providers">
			<list>
				<ref local="daoAuthenticationProvider"/>
			</list>
		</property>
        <property name="sessionController" ref="sessionController"/>
    </bean>

And you’re ready to run.

Some users have encountered problems with concurrent logins: If a user logs out, and then tries to log in again, the ConcurrentLoginException is thrown, so user cannot log in again. This happens when Acegi logout does not remove the session data for the user that has been logout out (before his login session has expired)
In order to fix this, you can manually clear the authentication session for the user that’s logged out:

public void logout() {
        SecurityContext context = SecurityContextHolder.getContext();
        if (context == null) return;
        Authentication authentication = context.getAuthentication();
        if (authentication == null) return;
        String sessionId = SessionRegistryUtils.obtainSessionIdFromAuthentication(authentication);
        this.sessionRegistry.removeSessionInformation(sessionId);
}

You will also need this code to be run when Acegi session gets unpublished.
For this implement org.acegisecurity.ui.session.HttpSessionEventPublisher, and configure listener for it in your web.xml:

public class MyHttpSessionEventPublisher extends HttpSessionEventPublisher {
    private static final Log logger = LogFactory.getLog(MyHttpSessionEventPublisher.class);
    private UserContext userContext;

    public void sessionDestroyed(HttpSessionEvent event) {
        logger.info("unpublishing session");
        if (userContext == null) {
            this.userContext = lookupBean(
                        WebApplicationContextUtils.
                             getWebApplicationContext(
                              event.getSession().getServletContext()),
                       "userContext",
                       UserContext.class);
        }

        this.userContext.invalidate();
        super.sessionDestroyed(event);
    }

    private  T lookupBean(final ApplicationContext applicationContext, final String beanName, final Class c) {
        //noinspection unchecked
        return (T) applicationContext.getBean(beanName, c);
    }
}

In web.xml you will have:

<listener>
        <listener-class>net.cakesolutions.service.security.acegi.BimHttpSessionEventPublisher</listener-class>
</listener>

And you’re ready to go.

Hope this article has helped anyone in configuring concurrent logins with Acegi Security.

Malicious user can change any header of your message this way, to, cc, bcc fields, content-type, even the actual message.

Message body can be changed in the same way, only without the header name. But note that body added like this will be PREPENDED to the email message. So if someone uses your email form to send an email message with new body he/she can enter the follwing in the available form filed (in our case recipient address):

recipient email: johndoe@serbiancafe.com%0Asubject:this is new even subject.%0AThe Spam message body, you didnt want this, but it will come to your inbox

And without knowing it, your ‘email this page to a friend’ form will become the source of spam!

Now how to resolve this issue?
You shpuld check all the fields that are available for user input in your email form for and characters (’\n’ and ‘\r’ in your java code).

You have two approaches available. You can either:
1. reject to send any email that contains any of these characters (recommended)
2. remove the characters and send the email as it is

The java code that does this is very simple:


public static boolean isHeaderInjection(String value) {
if (value == null) return false;
if ((value.indexOf("\n") != -1 || value.indexOf("\r") != -1) || value.indexOf("%0A") != -1) {
return true;
}
return false;
}


Make sure to check all your email form fields, and you should be safe from this kind of attack.