Seaside issues multiple cookies for different paths

[theseion]

Redirects on a page can cause Seaside to issue multiple session cookies. Example

1. client goes to example.com/some/path/
2. Seaside issues session cookie which the browser saves with an implicit path of '/some/path/'
3. client goes to example.com/other/
4. Seaside issues a second session cookie which the browser saves with an implicit path of 'other/

This is bad for two reasons three reasons:

• unnecessary sessions are created
• session state is lost across the same domain
• can lead to infinite redirects (see issue Deleting session cookie with redirect can lead to infinite redirects #916)

[theseion]

Setting the session cookie path to '/' fixes this. Maybe this should be configurable somehow, as there may be valid use cases for having multiple session cookies for different paths on the same domain.

See also issue #917

[marschall]

I don't think setting the session cookie path to / is a good idea. Different WAApplication instances under different paths must no share sessions or session cookies.

In the example you give, what is the path of the WAApplication?

[theseion]

That is true. So it should probably be the path of the application. My use case is a bit different, as I need to map requests to the proxy server on to an application, e.g. '/some/path' is mapped to '/application/some/path'. That means, that I need to set the path on the cookie as '/', not '/application'. But I can make that a behaviour specific to our application.

The path of the application in the example would be '/application'.

[marschall]

Yes, it should be the path of the application, but that should already be happening, see WARequestContext >> #newCookie.

If you do not want to rewrite the cookie paths in your proxy server and do not want to make the the paths in the proxy server and Seaside match my recommendation would be to implement a custom WACookieSessionTrackingStrategy. There you can do exactly what you need.

[theseion]

You're right. The problem in my case was that I have set my application url to '/', which, because of issue #917, was set to the empty path. A fix for #917 should, therefore, also fix this issue.