[GitHub] [tomcat] ChristopherSchultz commented on issue #162: Add support for same-site cookie attribute

2019-05-15 Thread GitBox
ChristopherSchultz commented on issue #162: Add support for same-site cookie 
attribute
URL: https://github.com/apache/tomcat/pull/162#issuecomment-492771440
 
 
   +1 for making `SameSiteCookies` into an `enum`. It will also protect against 
a malicious application causing Tomcat to emit a broken/malicious HTTP response 
header.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[GitHub] [tomcat] ChristopherSchultz commented on issue #162: Add support for same-site cookie attribute

2019-05-13 Thread GitBox
ChristopherSchultz commented on issue #162: Add support for same-site cookie 
attribute
URL: https://github.com/apache/tomcat/pull/162#issuecomment-491889201
 
 
   Thank you for the proposed patch.
   
   Understanding that changing the definition of a class in the `javax.servlet` 
namespace (namely, `Cookie`) has some challenges, it seems to me that this is 
the wrong approach. I think the right approach is to allow individual cookies 
to have the "samesite" setting set individually.
   
   Changing `Cookie` would allow fewer changes to the core API and the 
`SameSiteCookies` class (which should be an `enum` IMO) would not need to exist.
   
   What are our options when it comes to messing-around with the servlet API 
classes?
   
   Would it be better to apply a variant of this patch wait for another servlet 
spec release to "fix" the Cookie API? Or would it be better to provide another 
(different) container-specific workaround for things in the meantime? As much 
as we all hate system properties, this might be a good time to use one, since 
(a) it's intended to be temporary (pending a spec revision) and (b) it will 
require fewer changes to the internal Tomcat API which will just have to be 
un-done when the spec revision is published.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org