DO NOT REPLY [Bug 18004] - JDBCRealm.authenticate() eats SQLExceptions and should not
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004 JDBCRealm.authenticate() eats SQLExceptions and should not [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-08-08 17:19 --- As already stated, the realm does logs the exception so any error which is occuring may be discovered by the server administrator. For security purposes, the user should be denied access with the default webapp or container error message. Anything less is a security violation. This will NOT be fixed in tomcat. If this is still an issue, I recommend extending JDBCRealm (which is a non-final class) with your proposed fix and deploy it to $CATALINA_HOME/server/classes dir (as well as following all the needed instructions for writing a custom realm) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18004] - JDBCRealm.authenticate() eats SQLExceptions and should not
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004 JDBCRealm.authenticate() eats SQLExceptions and should not --- Additional Comments From [EMAIL PROTECTED] 2003-03-14 20:01 --- The only place that the actual cause of such a problem should show up is in the log files -- telling the user what the actual problem was just opens your app up to security attacks. Good security design says that the result of an are you authenticated question is a yes or no, with no further information available to potential attackers. I'm not an active Tomcat committer at the moment, but I strongly argue for a WONTFIX resolution on this one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18004] - JDBCRealm.authenticate() eats SQLExceptions and should not
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004 JDBCRealm.authenticate() eats SQLExceptions and should not --- Additional Comments From [EMAIL PROTECTED] 2003-03-14 20:27 --- Craig, I really wish you had to eat your own cooking on this one. I don't think you realize how many support requests, how much confusion, and how much frustration are generated because of this feature. The only information that needs to be communicated to the user is We cannot log you in at this time due to a system error. Please try back later. Many large websites do this, and it is a flaw in Tomcat that it cannot. A simple error message like the one I just mentioned is not going to reduce security in any significant way. The benefits outweigh the costs, big time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18004] - JDBCRealm.authenticate() eats SQLExceptions and should not
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004 JDBCRealm.authenticate() eats SQLExceptions and should not --- Additional Comments From [EMAIL PROTECTED] 2003-03-14 21:25 --- Been there (dealt with user support issues) ... done that (tried to make error messages more helpful) ... and I've seen server containers that behave the way you propose get themselves published on CERT advisories for having security vulnerabilities (what you want is *totally* against basic Security 101 design principles). I'm not interested in seeing that happen to Tomcat. If you deploy an app that throws a JDBC exception in the authenticate method (say, because you mis-typed the name of one of the columns in the config), that is first and foremost a flaw in your application testing and deployment practices, which needs to be addressed before you even start thinking about how the server might be more responsive to reporting these problems to the ultimate end user. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18004] - JDBCRealm.authenticate() eats SQLExceptions and should not
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004 JDBCRealm.authenticate() eats SQLExceptions and should not --- Additional Comments From [EMAIL PROTECTED] 2003-03-14 21:35 --- Is Yahoo Mail listed on one of these CERT advisories? Because Yahoo Mail has the functionality for which I am asking. And if Yahoo Mail is on a CERT advisory, I would have to question the practicality of these advisories. I agree with you about the mis-typed column name; this is something that should come out in testing. What I am most concerned about is database downtime. As hard as we try to keep it from happening, databases do go down from time to time. This kind of problem really is a RuntimeException, and I don't see the harm in telling the user You can't log in right now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18004] - JDBCRealm.authenticate() eats SQLExceptions and should not
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004 JDBCRealm.authenticate() eats SQLExceptions and should not --- Additional Comments From [EMAIL PROTECTED] 2003-03-14 21:45 --- One more thing on this topic and then I'll shut up: Making the change I am asking for does not preclude anyone from keeping the end- user experience exactly the same as it is now; anyone can eat the exception anywhere down the line. But implementing my suggestion will give people a CHOICE about how they want their site to behave, a choice we do not have now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18004] - JDBCRealm.authenticate() eats SQLExceptions and should not
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18004 JDBCRealm.authenticate() eats SQLExceptions and should not --- Additional Comments From [EMAIL PROTECTED] 2003-03-15 06:23 --- *THANK YOU* for this warning! If Yahoo has shown you a database exception at login time, that's the last security straw in my book -- there have now been enough security-related problems reported against Yahoo that I will never ever use them again. I've just stopped using my last Yahoo id because of this. (If you have a clue who I am, and what my involement with Tomcat has been, you might want to take this seriously for yourself.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
