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 ------- Additional Comments From [EMAIL PROTECTED] 2005-07-18 16:33 ------- (In reply to comment #6) > 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. BZ is not a discussion forum for development. I am using this post to either: a) make you go away and annoy other developers b) use the proper communication medium, aka tomcat-dev > 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. I am talking about setting a session cookie for another domain, not reading cookies. > 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. Well, find another project to cooperate with, then ;) > 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. Obviously, only SSL can ever hope to be secure. If you need security, use SSL and you have a hope of being secure, everything else is just hacks. > 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. Again, feel free to go elsewhere :) > This behavior is sometimes called "corrupt" although I am not saying that you > are necessarily corrupt. Corrupt is fine by me, I've been called far worse. > 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. This is huge and very costly. Besides, it is useless security. > 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. I think the session manager, as done in Tomcat and likely all other servers, is a decent, balanced solution. If you have specific needs, you should be able to devise your own custom solution. As usual, I see a lot of willingness to shove down the throat of everyone your own little needs (and/or preferences), just to save some maintenance time on your part. I will close this without further comments as WONTFIX if reopened. If you want to talk about this, please use tomcat-dev (although I will ignore the discussion thread, and block any proposed change to the default behavior). -- 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]
