Question

Before Spring Security/MVC, I had a simple relatively insecure userobject stored in my sessions that held a lot of data and that I’d update in my service logic and then store back in session with every modification.

Now I’ve successfully locked down my userobject as a Principal object with the same complex data structure. As before the userObject is available to the view after authentication with it’s initial state stored in it, but it seems my userObject implementing UserDetails is now not changeable (without creating a new Authentication Object on each request). It certainly cannot just be stashed back into the SecurityContext modified as I used to do with my session.

So I’m thinking I either need to:

A. restructure my UserObject to get all that other stuff out of there and add them to the session after authentication with a custom filter,

B. create a new authentication object after each change (sounds super expensive….)

C. some other thing that I haven’t yet seen or understood…

I’ve checked many answers and it seems a common problem, but none address my specific concerns/questions. AM I missing something really obvious here?

Answer 1

I don’t think you’re missing anything. The intent of a UserDetails object is for it to be immutable. It’s supposed to be loaded by a UserDetailsService as part of an authentication process.

I would vote for A: restructure your user object and put as little in the session as possible. Really the user object should only be storing the authorities relevant to your application, and possibly user attributes that don’t change very much (name, title, etc.) and only if the application needs them for display or processing purposes. It should not be storing data you’re accumulating as the user uses the application (tracking habits, clicks, etc.). That should be stored elsewhere, such as in a database.