Spring Security
  1. Spring Security
  2. SEC-1709

AbstractAuthenticationToken does not define a serialVersionUID

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.5
    • Fix Version/s: 3.1.0.RC2
    • Component/s: Build and Admin
    • Labels:
      None

      Description

      Similar to SEC-338, org.springframework.security.authentication.AbstractAuthenticationToken does not define a serialVersionUID. This is causing failures in our development environment because we pass an authentication token around in RMI (thus the serialization). The exception is:

      2011-03-26 13:29:11,278 ERROR [STDERR] (http-0.0.0.0-8280-1) Caused by: org.springframework.remoting.RemoteAccessException: Could not access remote service [rmi://x.x.x.x:x/RmiAdapter]; nested exception is java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
      java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
      java.io.InvalidClassException: org.springframework.security.authentication.AbstractAuthenticationToken; local class incompatible: stream classdesc serialVersionUID = -3194696462184782834, local class serialVersionUID = 1043617290326266361

      Please add a serialVersionUID to AbstractAuthenticationToken and it's subclasses. Or, since this has come up before in other classes (SEC-338, etc), add serialVersionUID's to all serializable classes. It's an Eclipse compile option that we require for all of our code.

        Activity

        Hide
        Luke Taylor added a comment -

        This isn't a major bug, as it has been a deliberate policy to avoid making any guarantee of compatibility of serialized classes between versions. Serialization is a bit of a minefield and a maintenance headache, so we have avoided attempting to maintain a serializability contract between versions.

        I would recommend that you use the same Spring Security version on both client and server, and it may also be a good idea to customize the Authentication object used and implement readObject and writeObject explicitly. This may also allow you to produce a more compact representation which would be preferable for use in client/server applications.

        Show
        Luke Taylor added a comment - This isn't a major bug, as it has been a deliberate policy to avoid making any guarantee of compatibility of serialized classes between versions. Serialization is a bit of a minefield and a maintenance headache, so we have avoided attempting to maintain a serializability contract between versions. I would recommend that you use the same Spring Security version on both client and server, and it may also be a good idea to customize the Authentication object used and implement readObject and writeObject explicitly. This may also allow you to produce a more compact representation which would be preferable for use in client/server applications.
        Hide
        Jeff Martin added a comment -

        I should have mentioned it but we are using the same Spring Security version on the client and the server. The difference (for us) is that even minor releases of the JDK affect how the serialVersionUID is calculated if not explicitly specified (Sun/Oracle Java 6.0.16 and 6.0.23 in this case).

        Show
        Jeff Martin added a comment - I should have mentioned it but we are using the same Spring Security version on the client and the server. The difference (for us) is that even minor releases of the JDK affect how the serialVersionUID is calculated if not explicitly specified (Sun/Oracle Java 6.0.16 and 6.0.23 in this case).
        Hide
        Luke Taylor added a comment -

        Hmm. That is a pain. I would have expected the JVM algorithm to be the same. In fact it sounds like a VM bug. Given that's the situation, we should probably conside adding a fixed ID, even though we will still explicitly require that the same Spring Security version is used.

        Show
        Luke Taylor added a comment - Hmm. That is a pain. I would have expected the JVM algorithm to be the same. In fact it sounds like a VM bug. Given that's the situation, we should probably conside adding a fixed ID, even though we will still explicitly require that the same Spring Security version is used.
        Hide
        Luke Taylor added a comment -

        I've added a fixed static value to the SpringSecurityCoreVersion which is now used as the serializationVersionUID values for security context, authentication tokens and related classes.

        Commit log was accidentally labelled as SEC-1700.

        Show
        Luke Taylor added a comment - I've added a fixed static value to the SpringSecurityCoreVersion which is now used as the serializationVersionUID values for security context, authentication tokens and related classes. Commit log was accidentally labelled as SEC-1700 .

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Jeff Martin
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: