Session mix up - apache httpd with mod_jk, tomcat, spring security - another user's service data

Question

Recently, we have had a serious problem: one user was provided with the data of another user. This problem is almost impossible to play.

We use the standard log management provided by Spring-security, and we are sure that the problem is not to store the user in an instance variable or similar concurrency thing in our application.

We really doubt that the problem is SpringSecurity or Tomcat.

Our front-server is apache httpd connected to tomcat via the ajp connector (mod_jk). We do not perform load balancing (httpd only cares about SSL, some rewrite URLs and serve some php modules)

Here is our setup:

## OS OS Name: Linux OS Version: 2.6.32-5-686 Architecture: i386 ## Apache httpd Server version: Apache/2.2.16 (Debian) Server built: Sep 4 2011 20:27:42 ## mod_jk mod_jk/1.2.30 (installed via apt-get) ## JVM JVM Version: 1.6.0_18-b18 JVM Vendor: Sun Microsystems Inc. ## Tomcat Server version: Apache Tomcat/6.0.28 Server built: February 12 2011 1443 

We blame httpd / mod_jk for this session, so our only solution is to remove apache httpd. But before leaving this popular and widely used configuration, we would like to know if I encountered a similar problem.

The only similar problems I discovered were in load balancing or mod_jk.

Have you ever encountered a similar problem? Any hints, ideas, links or experience would be greatly appreciated. Thank you

Answer 1

One possible problem may be a second login attempt. Consider the following case:

• The user opens two browser tabs with two login formats.
• Tab 1: Log in as user_1. Upload some data to an HTTP session.
• Tab 2: log in as user_2. Upload some data to an HTTP session.

In most browsers, this will be the same HTTP session. That way, you will have the data from user_1 and user_2 combined into one HTTP session. Any page that uses session objects may be affected.

You have two options:

• Prevent this situation. Identify the second login attempt and ask the user to log out first. Easy with Spring Security, see the code below.
• If you absolutely need one account on the browser tab, you can save your session data on the map for each username.

You can prevent a second login attempt using Parallel fetaure session control:

 <http> ... <session-management> <concurrency-control max-sessions="1" error-if-maximum-exceeded="true" /> </session-management> </http> 

Is this already done in your application?

Answer 2

If you eliminate the problem of a parallel session, then pretty much the only possibility is that your business logic itself is erroneous and serves other user data. Please send code samples as defined by the "current user" and then used.

EDIT: errors that occur only in production are often caused by race conditions ( http://en.wikipedia.org/wiki/Race_condition ). Make sure your code uses local variables whenever possible, and use lock / sync if applicable.

Answer 3

So far, we have not been able to reproduce the error, but we have found that some people are facing the same problem with mod_jk:

• https://issues.apache.org/bugzilla/show_bug.cgi?id=47714
• http://grails.1312388.n4.nabble.com/Spring-Security-after-log-in-user-changed-and-session-mixed-up-td4636714.html (below)

So, now we run the following settings:

• JkOptions DisableReuse: http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
• worker retries = 0: http://tomcat.apache.org/connectors-doc/reference/workers.html#Advanced Work Directives

And we plan to switch mod_jk to mod_proxy_http.

I leave this question unanswered, because I cannot assure (and no one came across the same problem to make sure) that the solution corrects the error.

If anyone could share any information, I would really appreciate it! Thanks.

Answer 4

When you integrate JSF and Spring, JSF dependency injection conflicts with Spring dependency injection, so Spring has rewritten the JSF module that handles this instead of Spring DI instead. Therefore, when I declare the JSF ManagedBean as a Session Scoped, I must also give it the @Controller annotation @Controller that it is recognized as a Spring Bean.

For more information, see this.

Answer 5

I ran into the same issue with Glassfish 3.1.2.2 and Mod_JK 1.2.19

You can reproduce the error with a JMeter script and a good statement.

Here is my blog post telling the story: http://jeecookbook.blogspot.com/2013/07/modjk-session-mixed-between-users.html

Using Mod_proxy with this statement solves the problem: no more mixing was detected.