Contrib.social

Status messages block visibility does not behave as expected.

Open on Drupal.org →
Created on 4 November 2021, about 3 years ago
Updated 9 September 2023, over 1 year ago

At the moment (many) error and warning messages which are handed over to the Status messages Block will be displayed to Anonymous (not logged in) user via the Status messages block by default on themes enabled by site builders without checking the Block layout settings page. The Status messages block has a default occurrence on every theme without access limited permissions, which makes it appear on most themes for every user without knowledge of the unexperienced site builder. What means: visible for every not logged in user by default.

Problem

Unexperienced users would not expect that to happen and maybe lead them not to control/test it. This creates security concerns for projects which do not want to show potential hackers that the project has a Drupal directory structure or certain errors or problems. Some errors even indicate the Drupal or PHP version running.

Experienced users know that it is best practice to change the permission on the Status messages Block to roles which have to manage and handle all the messages. But they have to do that on every theme installed for testing. Unexperienced users will only find out by accident.

Solution

Since the Status messages block seems to be setup and added mostly to any theme by default, we maybe should be consequent on the default and discuss to set up Status messages block to be visible for logged in users only by default on every theme and Block layout added.

🐛 Bug report
Status

Active

Version

10.0 ✨

Component
Block  →

Last updated 1 day ago

Created by

🇫🇷France dqd London | N.Y.C | Paris | Hamburg | Berlin

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇫🇷France dqd London | N.Y.C | Paris | Hamburg | Berlin

    Well, after re-thinking and humbling over this again after 2 years, I still see good reasons for keeping this open or re-opening it. I am still intuitively confused about the behavior of the messages block, what (again:) maybe indicates that something is still not at it's best (UX wise). And new tests even extend this issue even more (will edit issue summary for this).

    And to make sure that my concerns are well seated we started some UX tests with average users here. With the result: The users start to wonder: "Which block delivers warnings and errors if not messages?"

    Exactly - Like for me: My assumption was always it is "messages"? And in fact it is but it doesn't react like expected. The users experienced the following behavior: First of all they wonder that the not logged in user sees error and warning messages. I explained them that I agree with their assumption that this should be turned off by default. Which were my original concerns in this issue. Let's call it part one. But now the interesting extension of the problem (part two): The user intuitively goes to admin/structure and uses the provided option here to set the visibility to "authenticated user" and is even more confused afterwards: it shows messages even if block visibility is set to "authenticated user" (of course: on a correctly set-up test while being logged out in another (2nd) browser.

    Do we still say this is like designed? I would be really confused if we say "works like designed".

    I disagree here
    Errors don't show if you turn them off from admin > config > development > logging

    And again (I was a little bit shy and started to worry about possible language barriers 2 years ago but I think it is not the case here): This issue is not about Errors and is not about to turn Errors off. It is about that the messages block does not act as assumed by users and that it does not react on setups made on block visibility settings (which is part two, what means, new in this discussion).

  • Comment over 1 year ago →
    🇫🇷France dqd London | N.Y.C | Paris | Hamburg | Berlin
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024