If I set my site to display no system error messages to end users, under some circumstances, they can still be shown due to the fact that the setting itself typically comes from the database (though it is possible to set it in settings.php) and there is a window in between setting up the drupal error handler and reading this setting from either database or cache where error messages default to being shown to end users. This seems at best inconsistent, and at worst a potential security issue, depending on what is revealed by the error message (I'd hope nothing too serious would be in those messages, but you never know). Note that this was first noticed on a D7 site, but the same happens in D8 also.
A real world example of how this can cause problems is if your error_level is set in the database rather than in settings.php, and your site uses memcache - a not too unusual setup:
If you then assume that a site using memcache might also use a caching proxy, then things get fairly nasty, as the messages in $_SESSION for anonymous users will cause your caching proxy to not cache their requests (due to the session cookie).
Here's a simple way to simulate this kind of error:
1: Set errors to hidden: https://skitch.com/e-alanevans/er335/logging-and-errors-testd8err.localhost
2: Trigger an error some point before variables are loaded (and imagine that this could be something like a memcache server being down)
diff --git a/core/includes/bootstrap.inc b/core/includes/bootstrap.inc
index 64872be..521d09e 100644
--- a/core/includes/bootstrap.inc
+++ b/core/includes/bootstrap.inc
@@ -2416,6 +2416,7 @@ function _drupal_bootstrap_variables() {
require_once DRUPAL_ROOT . '/core/includes/lock.inc';
// Load variables from the database, but do not overwrite variables set in settings.php.
+ trigger_error('TEST VARIABLES', E_USER_ERROR); // <--------
$conf = variable_initialize(isset($conf) ? $conf : array());
// Load bootstrap modules.
require_once DRUPAL_ROOT . '/core/includes/module.inc';3: load a page https://skitch.com/e-alanevans/er35h/welcome-to-testd8err.localhost-test...
I believe the solution is simply to set the default on displaying errors to hide them. It really depends though on whether drupal installed out of the box is considered a development setup, or a production setup. I think the safer assumption is the latter (because you can always enable error messages if you want them). At the moment, if you want to hide these error messages, you have to either do it in settings.php, which may not be practical, and may not be sufficient in extreme edge cases where an error is triggered before settings.php is available (I have no examples for this). I'll add a patch for this shortly. I think the approach needs some discussion though.
As a partial workaround you can always making sure your error_level is set in settings.php - that significantly reduces the window where errors can be displayed to end users. There is very little in the code in between setting up the error handler and loading settings from settings.php that could trigger errors (I'm sure it could be forced if you try really hard, but under normal circumstances shouldn't happen).
Determine whether the proposed solution is desired.
Review + revise.
If the change is accepted, error messages are assumed by default to be hidden until explicitly changed to show. Error logging should be unaffected, just the display in drupal_set_message()s.
Postponed: needs info
11.0 🔥
Last updated
After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Checking in on the issue that has not had discussion for 7 years.
Is this still relevant to Drupal 10?
Since we need more information to move forward with this issue, I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!