Project: Drupal Version: 4.4.1 Component: database system Category: bug reports Priority: normal Assigned to: Goba Reported by: Goba Updated by: Steven Status: patch Friendlier error messages and pages, okay. But I still think we should display the error string visually somehow, even to end-users. We cannot distinguish end-users from admins. I believe Drupal should offer enough meaningful information in every situation. Even if they can't understand what it means, at least they can copy-paste it so others can. Otherwise we'll have to make a checklist of various things that can trigger a db error at that point, and paste it to anyone who asks about seeing such a vague error screen. Steven Previous comments: ------------------------------------------------------------------------ May 30, 2004 - 16:06 : Goba Attachment: http://drupal.org/files/issues/Drupal-honour-display-errors-in-db-connect.pa... (903 bytes) The MySQL database connection part of the code emits error messages, which contain sensitive information about the server (eg. the file system path of the socket). Even if you disable display_errors, this is still displayed, though it should not. Here is a patch, which honours the display_errors setting and only emits the error message if the server admin's desire is to see error messages in the browser. BTW this patch is against 4.4.x CVS, while this is also an issue in the HEAD version (but the install system changes are said to contain some remedy for nonexistent database connections). If it is desired, this can also be applied against HEAD. ------------------------------------------------------------------------ May 31, 2004 - 23:11 : ax Attachment: http://drupal.org/files/issues/common.inc_1.patch (1.34 KB) there are more places where sensitive information is revealed via error messages. see SQL error for bad URL parameters [1] for an example. thats why i think this issue should be handled more generally than only fixing the mysql connection part. that is, /all/ errors should only be displayed if display_errors in php.ini is set. patch (incl. some s#"#'#g) attached. [1] http://drupal.org/node/view/4273 ------------------------------------------------------------------------ June 1, 2004 - 15:15 : Goba Ax's patch is complementary to mine. The error handler is registered way after the database connection is attempted. ------------------------------------------------------------------------ June 3, 2004 - 12:35 : Kjartan What are the odds of the install system making it for 4.5? I am not really up to speed on its development. If the install system is ready for 4.5 I don't see a reason to apply Goba's patch yet. Ax: care to make a separate issue for your patch and explaining why you remove error_reporting()? With your patch when display_errors is enabled it will also show @function, which indicates that any error SHOULD be ignored. ------------------------------------------------------------------------ February 5, 2005 - 01:24 : Steven We now have our own toggle for displaying error messages or not, but of course it cannot be read with database access. Still, I'm not entirely convinced about this patch. Installations with display_errors=off will offer admins no clue whatsoever as to what is wrong. Without these error messages, nothing gets logged at all (no watchdog possibility yet at that point), leaving admins no indication whatsoever of what went wrong. ------------------------------------------------------------------------ February 5, 2005 - 15:02 : Goba So then we can have either a one line error message in the die (but definitely not the mysql_error() output), or we can have a standard error.html shipped with Drupal, which is a friendly error message to the user. Steven, you complain about admins not getting to know about the error, but mostly end users will see such an error message, and not the admins, and they should not see the mysql_error() return value. Even if it does not contain sensitive information, it is far from friendly error handling. BTW on Weblabor.hu, we solved this problem with HTTP redirecting the visitor to http://weblabor.hu/hiba.html [2] (which is our error.html basically) in case of this low level database error. [2] http://weblabor.hu/hiba.html -- View: http://drupal.org/node/8143 Edit: http://drupal.org/project/comments/add/8143