[drupal-devel] [bug] Honour display_errors when displaying database connection errors

[Steven]

 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.patch (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