Hey Mark,
If you see a bug report, then that will mean I was able to reproduce it. I
see different behaviors in our local docker environment. Still, it's
nowhere as complex as our production environment--where everything is
clustered and behind load balancers, etc... It probably would be easier
for me to reproduce in our pre-prod environment and attach a debugger to
see where the / is coming from.
I glanced at the code, and SessionConfig is the only place setting the
CookiePath to / might happen. Would you agree?
} else {
// Only handle special case of ROOT context where cookies require a
// path of '/' but the servlet spec uses an empty string
if (contextPath.length() == 0) {
contextPath = "/";
}
}
--
Thanks,
Dan
On Sat, Jan 27, 2024 at 12:12 AM Mark Thomas <ma...@apache.org> wrote:
> On 26/01/2024 22:22, Dan McLaughlin wrote:
> > Hey Konstantin,
> >
> > Thanks for the reply.
> >
> > I synced the source last night. I haven't had a chance to step through
> with
> > a debugger yet. But the only way I could get the Cookie Path set was to
> > modify the context.xml and add sessionCookiePath to every application.
> I'm
> > pretty sure this wasn't how things worked in the past. And the
> > documentation even states (or how I interpret it) that the cookie path
> > should default to the context path if cookie path isn't set by the app or
> > in the context.xml. We don't set it anywhere in our code that I could
> find,
> > and it's not in our web.xml either. I also checked the server.xml and
> > context.xml in catalina base, and nothing sets anything related to the
> > session cookie.
> >
> > Locally in docker, I could confirm that if you don't set anything except
> > the cookie processor, then you end up with a JSESSIONID with a cookie
> path
> > that is the same as the context if it's not the root context. But if you
> > try to set sessionCookie in the context.xml for the app to
> > _Secure-JSESSIONID and you don't set the sessionCookiePath, then your
> > cookie path will be / regardless of what the context path is.
>
> I have tested this with a clean build of both 10.1.x and 11.0.x and both
> correctly set the path to "/examples" when I open the Servlet session
> example in the examples app with sessionCookieName="_Secure-JSESSIONID".
>
> > Seems like a
> > bug to me. If I have time to try some more tests and can confirm the same
> > using the examples web app, then I'll open a bug. We do
> > set privileged="false" in our context.xml so the only thing I can think
> of
> > is that the cookie processor or whatever code is managing the cookies is
> > blocked from calling the api's needed to check the context path and so it
> > defaults to /.
>
> Nope. Cookie processing doesn't require privileged.
>
> > Anyway, I'd have to do quite a bit more testing before I'd feel
> comfortable
> > opening a bug, but there looks to be changes in the areas related to
> > Sessions and Cookies lately, so I'm guessing at this point that one of
> > those changes introduced a behavior change.
>
> There have been a few changes but nothing that is likely to affect this.
> I don't recall any changes that touched cookie paths in a long time.
>
> This looks like an app issue (or an issue in a library the app uses) to
> me at the moment.
>
> If you are able to reproduce this on a clean install of the latest
> 10.1.x release (or any other currently supported version) I'd be happy
> to take another look. All we'd need would be the steps to recreate the
> issue from the clean install.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
*NOTICE:* This e-mail message and all attachments transmitted with
it are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure, or distribution is strictly prohibited. The contents of this
e-mail are confidential and may be subject to work product privileges. If
you are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.
