Joy
Joy

Reputation: 4463

How to fix java.io.InvalidClassException: org.springframework.security.core.context.SecurityContextImpl

I have recently upgraded the Spring of my spring boot application, as a result, the underlying Spring Security Core upgraded to 5.4.5.

Now while launching the Spring Boot application, I am seeing following issue:

org.eclipse.jetty.server.HttpChannel - handleException / java.io.InvalidClassException: 
org.springframework.security.core.context.SecurityContextImpl; local class incompatible: 
stream classdesc serialVersionUID = 530, local class serialVersionUID = 540

In this context, I found this post on GitHub: https://github.com/spring-projects/spring-security/issues/9204 and https://github.com/spring-projects/spring-security/issues/3736.

But I could not figure out how to solve this issue. Could anyone please help here? Thanks.

Upvotes: 4

Views: 6421

Answers (3)

Silviu Cristian
Silviu Cristian

Reputation: 1

Spring boot version updates from 3.1.3 to 3.3.4 (for all the modules). It was a problem because of Spring Security, obviously. Because it was a development project, I just deleted the entire development database and recreated it. I think the problem was caused by data stored in the two spring session tables in the database (because Spring Security stores data [SecurityContext] on session and was some data trouble because of the Spring Security Update and some generated data-value-structure incompatibility between versions).

** SOLUTION: So I think one viable solution could be to just to delete all session data of your application that was stored in database session tables (obviously if you store session data in the database).

You can find on the web this intel that makes me conclude this behavior, also thanks to the previously posted user answer: The SecurityContext mainly represents the persisted session. It contains an Authentication which in the context of a web application encapsulates the information of the authenticated user. The default implementation of the SecurityContextRepository stores the SecurityContext in the HttpSession.

Upvotes: 0

Tzahi Fadida
Tzahi Fadida

Reputation: 306

Converters or session repositories does not cover every session failure. Therefore I have made a hack, that on a specific path we kill the session on the browser side (since the server side jdbc/redis session load cannot recover). On my project the FE logout screen is available if there is an unrecoverable error.

@Slf4j
@Component
@Order(Ordered.HIGHEST_PRECEDENCE)
public class RecoverSessionFilter implements Filter {
    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException {
        try {
            chain.doFilter(servletRequest, servletResponse);
        } catch (Exception e) {
            if (((HttpServletRequest) servletRequest).getServletPath().endsWith("/logout")) {
                Cookie cookie = new Cookie("SESSION", null);
                cookie.setPath("/");
                cookie.setHttpOnly(true);
                cookie.setMaxAge(0);
                ((HttpServletResponse) servletResponse).addCookie(cookie);
            }
            throw e;
        }
    }
}

Upvotes: 0

Orhan
Orhan

Reputation: 1475

In https://github.com/spring-projects/spring-security/issues/9204 you can find: "Spring Security is not intended to be serialized between versions"

This is mind blowing. So all users need to be logged out on an version upgrade!?

What can you do? For your current upgrade you must log out all users. But you can prepare for next upgrade:

You need to write your own serialization for the session object. Here is one project where they added there own session serialization user Jackson with and some redis library. This code will work without changes even if you are using mysql for example:

https://raw.githubusercontent.com/klboke/apollo/091a757d0a3c2173d6c600cd6a9a1595bb73c10c/apollo-portal/src/main/java/com/ctrip/framework/apollo/portal/component/config/SpringSessionConfig.java

One thing to note. So if you are not in production then you add this configuration and when the security lib get upgraded you are fine, but if you are in production first time you deploy this all users will need to be logged out first as serialization of the session will not fit the previous one!

Upvotes: 4

Related Questions