Tags
People
Badges
Help-
CORE FRAMEWORK
FEATURED COMPONENTS
-
RESOURCES
-
LEARN ZK
RESOURCES
Hello,
I am working on a ZK 3.6.4 application that was using an old version of ZK Spring. I have recently updated it to use ZK Spring 3.1.1. We have updated it so that we could move the whole app to Spring Security 3.1.2.
As part of the update process, we've done two changes to the zk.xml:
- Enabled event threads, which is now disabled by default.
- Started using the new org.zkoss.spring.security.config.ZkSecurityContextListener, which should work just as well as putting the ThreadLocalSecurityContextHolderStrategy in the ThreadLocal list of the ThreadLocalListener.
Since this update, we have started seeing an intermittent issue in production. The SecurityContextHolder loses the Authentication object set up in the session after the user has interacted with the application for a while. It should contain a UsernamePasswordAuthenticationToken, but instead contains an AnonymousAuthenticationToken. It works like a charm for a while, but all of a sudden (and it can occur in many of our screens), the session loses the original Authentication object, and the Spring Security filter chain, then creates an anonymous one.
I am wondering if other folks have encountered a similar problem. It is very hard to reproduce in a development environment. I have come up with two possible causes for the issue after some investigation:
- The client-side JavaScript is making a request to the server in a new/different session. I don't know if that would be possible. I don't understand enough how the ZK framework does things on the client-side.
- The ZkSecurityContextListener, or the event loop processing code that calls this listener, has some thread synchronization issue that is causing the SecurityContextHolder to lose track of the authentication when the thread local is being transferred to/from the event loop thread from/to the servlet thread.
By the way, I have also seen the issue occur when I put the ThreadLocalSecurityContextHolderStrategy back into the ThreadLocal list and remove the org.zkoss.spring.security.config.ZkSecurityContextListener.
It is very strange because our application used to work just fine before we updated to ZK Spring 3.1.1.
If anybody encountered any similar issue, any hints on how to solve this issue would be greatly appreciated.
Thanks,
- Quenio
Hi, if possible
you should not use event thread, you should set
<system-config> <disable-event-thread>true</disable-event-thread> </system-config>
If you need to use event thread, refer to zk.xml file: the ThreadLocal issue
in zk.xml
<listener> <description>ThreadLocal Synchronization Listener</description> <listener-class>org.zkoss.zkplus.util.ThreadLocalListener</listener-class> </listener> <preference> <name>ThreadLocal</name> <value>org.springframework.security.core.context.ThreadLocalSecurityContextHolderStrategy=contextHolder</value> </preference>
I tested ZK 364 with spring security 3.1.2.RELEASE, it works fine
Changing the configuration to use ThreadLocalListener to copy the security context thread local (instead of using the ZkSecurityContextListener) seems to have resolved the issue in production so far.
I am still not sure why ZkSecurityContextListener has caused the issue we've seen in production.
Asked: 2012-11-19 06:44:05 +0800
Seen: 100 times
Last updated: Nov 21 '12
