Add Immediate Save Support

[rwinch]

Right now we try to save the session lazily. This can cause problems in some instances. We should provide a mechanism to save the session as soon as the attribute changes.

[bmorris591]

+1 for this.

Currently I modify sessions in ChannelInterceptor and ApplicationListener<ApplicationEvent> instances that handle various application events and store some useful attributes in the Session.

I have to manually call save on the session as the lazy save is only triggered (as far as I can see) by the SessionRepositoryFilter.

No automatic save occurs for WebSocket events.

[eladh]

+1 for this also

[andrewserff]

Another +1 from me. I described my problem in this question on StackOverflow.

[VitaliiH]

+1
Looks like this (Save session on Redis RedisSession.saveDelta) #311 is related to current discussion.

[persapiens]

+1
I'm having problem with graphicImage component from Primefaces.
The issue occurs because the component creates a link for the image while the original request is processed. In this case, the session is changed from node one, but the node two can't see the data because the request did not finish.
My workaround was to use ip_hash function of nginx.

[rwinch]

This was fixed in #273

[andrewserff]

@rwinch This still isn't working for me after trying out the fix. I've updated to Spring-Session 1.1.1 and have added the flush config like so to all of my microservices:
@EnableRedisHttpSession(redisFlushMode = RedisFlushMode.IMMEDIATE)

Then I restarted everything, quit my browser, launch browser, clear my cache, then try to hit one of my services though the edge server and I get a 403. Looking in the logs, the back end service still thinks that the user is the identity presented by the edge server and not the actual user. So it still doesn't seem to be replicating the session to the backend services fast enough. Is there something I'm missing. Again, here was my question on SO for reference.

[robwinch]

@andrewserff Its possible the issue is because Spring Security delays writing the user to the session until the end of the request. You could try writing the SecurityContext to the session manually and see if that helps.

[andrewserff]

@rwinch That doesn't seem to work either. I made a ZuulFilter like so:

@Component
public class SecurityContextSessionWritingFilter extends ZuulFilter {

    private static Logger log = Logger.getLogger(SecurityContextSessionWritingFilter.class);

    @Override
    public Object run() {
        //First we need to build the correct URL
        RequestContext ctx = RequestContext.getCurrentContext();
        HttpServletRequest request = ctx.getRequest();

        // Create a new session and add the security context.
        HttpSession session = request.getSession(true);

        SecurityContext securityContext = SecurityContextHolder.getContext();

        if (securityContext != null) {
            log.debug("Writing securityContext to session: " + securityContext);
            session.setAttribute("SPRING_SECURITY_CONTEXT", securityContext);
        } else {
            log.debug("Couldn't get the Principal to write to the session: " + securityContext);
        }

        return null;
    }

    @Override
    public boolean shouldFilter() {
        return true;
    }

    @Override
    public String filterType() {
        return "pre";
    }

    @Override
    public int filterOrder() {
        return 1;
    }

}

It successfully writes the SecurityContext to the session before the request is sent to the backend service, but still get denied on the backend...

[rwinch]

@andrewserff Any chance you can put together a demo of the problem?