[Bug 64921] LoadBalancerDrainingValve does not honour "Secure Session Cookie" settings

2020-11-19 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64921

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Mark Thomas  ---
Fixed in:
- 10.0.x for 10.0.0-M11 onwards
- 9.0.x for 9.0.41 onwards
- 8.5.x for 8.5.61 onwards

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64921] LoadBalancerDrainingValve does not honour "Secure Session Cookie" settings

2020-11-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64921

--- Comment #6 from Andreas Kurth  ---
https://github.com/apache/tomcat/pull/377

Windows smoke test failed due to an unrelated test failure.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64921] LoadBalancerDrainingValve does not honour "Secure Session Cookie" settings

2020-11-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64921

--- Comment #5 from Christopher Schultz  ---
That sounds good; I think there isn't any more configuration necessary, then
since the Cookie configuration already has what it needs.

I love one-liner fixes.

Andreas, would you care to prepare a patch/PR for this?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64921] LoadBalancerDrainingValve does not honour "Secure Session Cookie" settings

2020-11-12 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64921

--- Comment #4 from Mark Thomas  ---
You should be able to do this in the Valve:
SessionCookieConfig scc =
request.getContext().getServletContext().getSessionCookieConfig()

Then the logic used when the session cookie is created is:
sessionCookie.setSecure(request.isSecure() || scc.isSecure())

It should be possible to replicate that in the Valve.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64921] LoadBalancerDrainingValve does not honour "Secure Session Cookie" settings

2020-11-12 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64921

--- Comment #3 from Christopher Schultz  ---
Yes, I was thinking about some permutation of that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64921] LoadBalancerDrainingValve does not honour "Secure Session Cookie" settings

2020-11-12 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64921

--- Comment #2 from Andreas Kurth  ---
Setting "Secure" unconditionally would raise another issue: Chrome doesn't
accept the Secure flag when not run under SSL. A possible – still naive –
implementation might be:

if (request.isSecure()) {
sessionCookie.setSecure(true);
}

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64921] LoadBalancerDrainingValve does not honour "Secure Session Cookie" settings

2020-11-12 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64921

--- Comment #1 from Christopher Schultz  ---
Hmm. It's not possible to know whether or not the browser thinks the cookie
should be "secure" since the client doesn't send the "secure" flag to the
server (it's a one-way flag, from server -> client).

Are you able to test a patch (or have you already developed one)?

Assuming the only thing missing is:

  sessionCookie.setSecure(true);

then we only have to worry about knowing when to set that flag. Modern systems
should probably *always* set that flag, but someone out there surely needs is
to NOT set the "secure" flag so we need a way to disable that. Probably via a
configuration option "secure" which defaults to "true" but can be set to
"false".

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org