DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35709>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2005-07-18 16:12 ------- I am re-opening this because I guess there may be multiple misunderstandings and that these misunderstandings may be part of the decision to invalidate this bug. Remy: 1) "As for your issue, did you notice 3rd party cookies are allowed by default in browsers ?" This is IMHO unrelated to this issue. 3rd party cookies do NOT represent a security risk per se and cannot interfere with session logic. Nothing new. A page can have only one domain. a single script cannot be read cookies across domains unless the browser is broken. Content in a web page from multiple domains != cross site scripting vulnerability. 2) "You seem to have a bit too much time on your hands." This comment suggests that resources play an important role in judging the validity of the request. I would suggest that the resource question is deferred until later i.e. considered when this is due after evaluation, i.e. in a cooperative fashion compatible with the structure of this project. Voting after evaluation comes to mind. 3) "There are gaping holes in session security (without SSL), it's not worth trying to patch the existing model." a) If these holes are in Tomcat then they need to be fixed. Please supply bug numbers in that case. b) If you refer to the insecurity of the general architecture of session management with HTTP as it stands, then this would be even more a reason to have tomcat provide intrinsic security and give better support to struggling programmers. Tomcat is there to provide advanced frameworks that free programmers from hand coding these mechanisms. 4) "As I said, sorry, but I am not interested at all in this functionality, which would interest very few people, and yet introduce inefficient mechanisms and lots of complexity. If you have special needs, that's ok, but you're on your own." a) It is regarded unprofessional in a cooperative environment such as this to let an overriding personal interest get in the way of making balanced decisions. This behavior is sometimes called "corrupt" although I am not saying that you are necessarily corrupt. b) It is always considered worthwhile to plug a significant security hole in exchange for a minimal, sometimes major modification. "inefficient mechanisms and lots of complexity" - maybe - but likewise may be not in this case. One has to think it through first. c) "special needs". Ralf's needs are not special, they are quite generic. They can be condensed into the ubiquitous requirement to have a strictly limited single file download session within a major browsing session. It is a high priority business requirement to ensure that such sessions are not re-used by third parties. In a summary, it appears that there is an overwhelming number of reasons to finally start evaluating this request for enhancement. I would also suggest a less confrontational approach. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
