Stack Overflow Community,
I am facing a perplexing issue with the LTPA2 token in a Dockerized environment running WebSphere Application Server (WAS) version 9, following a migration from WAS 6. The problem is specifically related to the behavior of the token post-deployment, and I'm seeking insights or solutions.
Context:
- Migrated from WebSphere WAS 6 to WAS 9.
- The system relies on LTPA token for authentication.
- Deployments are automated in a Docker environment.
- Problem:
After each automated deployment, the system loses its reference to the LTPA2 token. This is evidenced by errors related to an "Empty cookie header string," indicating issues with LTPA token transmission or recognition. Intriguingly, a manual restart of the Docker container in which WAS is running temporarily resolves this issue. Post-restart, the LTPA2 token functions correctly, but this fix is not persistent through deployments. This issue does not occur when the Docker container is manually restarted, suggesting that the automated deployment process might be bypassing a crucial step that is otherwise covered in a manual restart.
Attempted Solutions:
- Reviewed SSO and LTPA settings in WebSphere post-migration.
- Examined cookie management in both WebSphere and Docker.
- Checked logs for relevant errors but didn't find any definitive leads.
Seeking Guidance:
Why would the LTPA2 token only function correctly after a manual Docker restart, and not persist through automated deployments? What might be missing or going wrong in the automated deployment process that a manual restart seems to address? Any suggestions for areas to investigate or potential fixes would be greatly appreciated.