What are the best practices to reload principal inside and outside (a cron application) of the application. This is a question originating by https://github.com/spring-projects/spring-session/issues/398#issue-137135814 and we have same problem. We have some workarounds to mitigate problem but it would be awesome to have a solution in the first place.

Comment From: rwinch

You would need to provide a custom SecurityContextRepository implementation

Comment From: cemo

Don't you think that this should be included in Spring Security?

Comment From: rwinch

@cemo I'm not sure I agree it needs to be in Spring Security, but should be in Spring. Spring Session provides a good way of doing this.

Comment From: cemo

@rwinch I will be glad that If you can expand a little bid your statement. What should be approach exactly?

Comment From: rwinch

You can access the session and update the attribute to the updated principal.

Comment From: cemo

I was considering an abstraction to mark user security context dirty by either a session or another approach and then reload it at first request. How does it sound? Does it worth being included in Spring Security Core?

Comment From: rwinch

How do you mark it as dirty? How do you reload the context?

Comment From: sambiomatters

@rwinch This issue actually prevents our use of Spring Security. We have done workarounds in the past, but it becomes very unwieldy to workaround if you use any other AuthenticationTokens besides the UsernamePasswordAuthenticationToken. There really needs to be a way to reload the principal in an AuthenticationToken type agnostic way.

A solution would be to let the user details and authorities to be lazy loaded, or delegated. The issue now is that Authorities are copied at login to the AuthenticationToken so it is impossible to delegate access to those authorities to a database lookup.

Comment From: lglapinski

@rwinch Is good way of doing this mentioned by you better than presented here?

Comment From: IARI

The Issue mentioned by @lglapinski (and #849 plus several others linked there) all relate to Redis sessions. Is it possible to achieve this with plain http-sessions as well?

@rwinch would a

custom SecurityContextRepository

be the way to go - and if so, can I just override HttpSessionSecurityContextRepository ?

And if i have done so and instantiated it in my WebSecurityConfigurerAdapter, Is it enough to register that as a bean? Does it need a special name?

Comment From: rwinch

You need to explicitly configure the repository

@Autowired
SecurityContextRepository securityContextRepository;

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .securityContext()
            .securityContextRepository(securityContextRepository)
            .and()
        ....
}

You can find a complete sample here https://github.com/rwinch/spring-security-sample/tree/gh-3849

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.