WebSphere 8.5.5 normally uses LTPA tokens for authentication and session cookies for tracking HTTP sessions. The two are not connected and they interact in a sometimes very frustrating way. The HTTP session expires when the user has been inactive (i.e. no requests have been received by the server) for a given time. The LTPA token on the other hand has a fixed expiration time regardless of user activity. This means that a user can be logged out while active and while still having a session. Furthermore it is tricky to handle this as any attempt to access the session for a logged out user fails with an UnauthorizedSessionRequestException, complaining that an anonymous user has attempted to access a session owned by someone else. What to do?
There is a configuration option described here and here that makes the session manager invalidate the session and return null instead. This works well as that is what web applications normally do when a user has been logged out, so it plays nicely with other security frameworks.
To enable the option pick Servers-Server Types-WebSphere application servers-servier name-Session management, find Additional Properties and select Custom Properties, then set InvalidateOnUnauthorizedSessionRequestException=true. Save the changes and restart the server. The UnauthorizedSessionRequestException is history!
If you have to use IBM’s JDK with WebSphere Application Server and like to unit test web services outside of the container, you may encounter:
java.lang.NoClassDefFoundError: com.ibm.ffdc.Manager at com.ibm.ws.ffdc.FFDCFilter.processException(FFDCFilter.java:82) at com.ibm.ws.webservices.engine.components.logger.LogFactory$2.run(LogFactory.java:159) at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63) at com.ibm.ws.webservices.engine.components.logger.LogFactory.createLogFactory(LogFactory.java:141) at com.ibm.ws.webservices.engine.components.logger.LogFactory.(LogFactory.java:98) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:205) at com.ibm.ws.webservices.engine.soap.MessageFactoryImpl.(MessageFactoryImpl.java:103)
What is that? A quick search indicates that the server administration client jar is missing from the classpath, but why would I need that? I just want to publish a simple JAX-WS web service.
Fortunately there is a workaround. Set a system property:
This forces the use of Sun’s web service stack and the problem is gone. When the code runs in the container the classes are available and in this way we can get the unit tests to work.