Hi Samuel,
On 4 Dec 2025, at 23:55, Samuel Pelletier <[email protected]> wrote:
> Cookies are limited to a path, check the response headers of your app, you
> should have something like this in direct connect:
I don't think that's the issue here, I'm doing URL re-writing in deployment,
but setting cookie "path=/".
> Even with that, ,my app still create new sessions so I decided to dig
> further. I did not bothered to check before but I noticed this behaviour
> before. After my investigation, I found a secret override that control this
> session creation. You simply need to override this method in your Application
> class:
>
> @Override
> public boolean shouldRestoreSessionOnCleanEntry(WORequest aRequest) {
> return true;
> }
>
> You may add logic, if the session if not found, a new one will be created.
I can safely say that I've never seen that method before in my life... Thanks!
So it turns out that one of my original observations was wrong:
> I see in the new tab that the wosid cookie is not being sent on the first
> request
That's not true, I just wasn't seeing it. It does send the original tab's
wosid, and with that method overridden does get the same wosid back in the
response—a new session is not created.
There is one remaining issue: on returning to the first tab, the first click on
any link still generates a page restoration error, though the user's session
remains, and then subsequent navigation is back to normal in both tabs. Any
thoughts?
--
Paul Hoadley
https://logicsquad.net/
https://www.linkedin.com/company/logic-squad/
