Working with Backdrop 1.29.0 on PHP 8.2.2. The Security Review comes up with "Untrusted users are allowed to input dangerous HTML tags."
It is recommended you remove the following tags from roles accessible by untrusted users.
- img
and says to review text formats.
On trying to configure the Basic settings (q=admin/config/content/formats/filtered_html) and unchecking Anonymous (or changing anything else) and then clicking Save Configuration, I get a 403 error.
<strong>Forbidden</strong>
You don't have permission to access this resource.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
I'm logged in as admin at the time and the same happens with trying to change
q=admin/config/content/formats/plain_text
and
q=admin/config/content/formats/full_html
All other sections of the admin seem to work fine, so wondering if there may be a setting issue or maybe a bug.
Any ideas? Thanks!
Comments
Hello zaphodm. Welcome to the Backdrop CMS forum!
I've tried to reproduce with a "clean" installation of Backdrop using PHP 8.2, with the Security Review module installed, but am not able to replicate the error. I'm able to edit the Basic (filtered_html) format without issues.
I'm wondering if this may be the result of some interaction with a contrib module that's faulty, or perhaps this is a Drupal 7 upgrade that had some issues that only show up when editing the text format.
To try to reproduce this, it would be helpful if you could provide more information. For example, what other modules are enabled, and whether this is a D7 upgrade. You can find useful info at admin/reports/debug
You should also check the Reports > Recent log messages to see if there are any other errors being logged before that fatal one, and report those here.
It's a clean install, rather than a D7 upgrade. The Backdrop logs show nothing beforehand or the event itself. The third-party modules are a possibility, I'll strip back to standard and investigate a bit more now that I know that others aren't seeing the same issue.
Are you logged in as User #1. Not all admins are equal. Sometimes, if permissions are not configured properly User #1 (superadmin) can do things that other admins can't.
This can happen if the admin role does not have full permissions:
In theory, user #1 (superadmin) can do these things, even if the boxes are not checked, but other admins are not able to do them.
Logged in as superadmin, yes.
Worked this out. Upon further investigation it wasn't just this page that had issues, but some others as well (but not all).
It was mod_security. Specifically the rules in REQUEST-920-PROTOCOL-ENFORCEMENT.conf that is part of the OWASP ModSecurity Core Rule Set V3.0.
Once that was turned off, everything now works great.
Thank you for your time and suggestions.