Access Denied - /concrete/controllers/backend/messenger.php(78): Exception->null

Installation
1

Hi all

I have recently updated a site form v8 to v9.1.3 and on every single page when logged into the editor we receive a popup with an access denied error on:

/concrete/controllers/backend/messenger.php(78): Exception->null

Here is the full stack trace:

/htdocs/updates/concrete-cms-9.1.3/concrete/controllers/backend/messenger.php(78): Exception->null
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Controller/AbstractController.php(318): Concrete\Controller\Backend\Messenger->consume
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Controller/AbstractController.php(318): null->call_user_func_array
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Routing/ControllerRouteAction.php(64): Concrete\Core\Controller\AbstractController->runAction
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/RouteDispatcher.php(37): Concrete\Core\Routing\ControllerRouteAction->execute
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/DispatcherDelegate.php(39): Concrete\Core\Http\RouteDispatcher->dispatch
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/MiddlewareStack.php(86): Concrete\Core\Http\Middleware\DispatcherDelegate->next
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/DefaultDispatcher.php(127): Concrete\Core\Http\Middleware\MiddlewareStack->process
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/DefaultDispatcher.php(60): Concrete\Core\Http\DefaultDispatcher->handleDispatch
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/DispatcherDelegate.php(39): Concrete\Core\Http\DefaultDispatcher->dispatch
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/FrameOptionsMiddleware.php(39): Concrete\Core\Http\Middleware\DispatcherDelegate->next
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\FrameOptionsMiddleware->process
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/StrictTransportSecurityMiddleware.php(36): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\StrictTransportSecurityMiddleware->process
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/ContentSecurityPolicyMiddleware.php(36): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\ContentSecurityPolicyMiddleware->process
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/CookieMiddleware.php(35): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\CookieMiddleware->process
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/ApplicationMiddleware.php(29): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\ApplicationMiddleware->process
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/Middleware/MiddlewareStack.php(86): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Http/DefaultServer.php(85): Concrete\Core\Http\Middleware\MiddlewareStack->process
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Foundation/Runtime/Run/DefaultRunner.php(125): Concrete\Core\Http\DefaultServer->handleRequest
/htdocs/updates/concrete-cms-9.1.3/concrete/src/Foundation/Runtime/DefaultRuntime.php(102): Concrete\Core\Foundation\Runtime\Run\DefaultRunner->run
/htdocs/updates/concrete-cms-9.1.3/concrete/dispatcher.php(45): Concrete\Core\Foundation\Runtime\DefaultRuntime->run
/htdocs/concrete/bootstrap/configure.php(52): null->require
/htdocs/concrete/dispatcher.php(18): null->require
/htdocs/index.php(2): null->require

I don’t get the error in my local dev environment but only on our prod server using PHP 8.1.

I don’t even know where to begin with this but I need a fix asap. I am hoping someone here can help?

Many thanks!

2

Hi @newmoon - so on your local are you running PHP 7 of some sort?

And you see this error only when you’re logged into the CMS in edit mode? Do you have any more detail about when / how it’s occurring?

3

Hi EvanCooper

Thanks for coming back to me! My local is running 8.0 where I don’t receive the error, live is running 8.1.

I receive the error on every single page visit on live when logged into Concrete. It is the first thing that pops up when the page loads, no matter what you do. Both on the front end and when in the dashboard pages.

I don’t know if this is related but the system is also throwing an exception on every single warning which is causing all sorts of problems. I don’t have “Consider warnings as errors” turned on, I have checked in the dashboard, the config files and the database and it doesn’t appear anywhere. I wondered though if this error is being thrown due to a warning somewhere in the stack.

Any advice you can give would be greatly appreciated!

Many thanks
David

4

Hmm I would try clearing the cache just to make sure there’s nothing weird going on in there - you can do that manually by just clearing everything in the /application/files/cache directory - or you can use the command line to clear the cache.

Always a good thing to rule out, and then if that doesn’t do the trick we can think of some other things.

Do you have anything non-default enabled in Concrete like public registration or anything like that? That might also help narrow it down if it’s an unknown bug in non-default functionality that just hasn’t been addressed yet.

5

Hi @EvanCooper

Many thanks for coming back to me. We have cleared the cache several times since relaunching but sadly with no change. We can still use the dashboard, we just have to clear the error message on every page we go to, after that, it seems to work fine. It’s just really annoying and slows everything down.

I suspect it is related to the second issue where warnings are being thrown as errors, I wonder if its not a true error but it is being treated as such which is why everything else still works.

We don’t have anything non standard enabled. It is a pretty straight forward marketing site, mostly built with blocks created through Block Designer Pro.

Any additional insight would be greatly appreciated.

Many thanks
David

6

Hi @newmoon - after reading this again, yes I think you will need to set your live stack to not treat warnings as errors - I would compare the error_reporting section of your php.ini on your local with the one on production - my hunch is the one on production is set to show warnings as errors which is going to cause lots of problems.

Here’s a link that might be useful: PHP: Runtime Configuration - Manual

Let me know if that does the trick.

7

Hi @EvanCooper

Thank you again for coming back to me. I can confirm that the settings are correct in PHP, it just seems to be something strange in Concrete itself.

Any other guidance you can give would be greatly appreciated!

Many thanks
David

8

I’ve got the same error going on with 2 of my websites, both from Concrete 8 → 9.1.3. To the best of my knowledge I’ve tried all the usual suspects, even completely replacing the concrete/ folder with a fresh installed one (because in rare cases that fixes weird issues) but that didn’t work either.

I noticed a couple other threads having this issue as well. I hope someone can provide a solution soon.

9

@newmoon (and future readers)

Unofficial workaround until the issue gets patched:

Copy concrete/elements/footer_required.php → application/elements/footer_required.php.

Right above View::getInstance()->markFooterAssetPosition(); add the following

$u = new User();
if ($u->isLoggedIn()) {
	echo '
		<div id="tempStyleUntilFix">
			<style>
				body .ui-dialog:has(strong),
				body .ui-dialog:has(strong) + .ui-widget-overlay{
					display: none !important;
				}
			</style>
		</div>
	';
}

And then at the end of the file add:

if ($u->isLoggedIn()) {
	echo '
		<script>
			$(document).ready(function() {
			    setTimeout(function() {
			        if ($(".ui-dialog")) {
			            console.log("Parent found");
			            if ($(".ui-dialog").find("strong").text() == "Access Denied") {
			                console.log("Child found");
			                $(".ui-dialog").remove();
			                $(".ui-widget-overlay").remove();
			                console.log("Elements removed");
			            }
			        }

					$("#tempStyleUntilFix").remove();
			    }, 1500);
			});
		</script>
	';
}

Or if you prefer regular javascript:

if ($u->isLoggedIn()) {
	echo '
		<script>
			document.addEventListener("DOMContentLoaded", function() {
				setTimeout(function() {
					let dialog = document.querySelector(".ui-dialog");
					if (dialog) {
						console.log("Parent found");
						let strong = dialog.querySelector("strong");
						
						if (strong && strong.textContent === "Access Denied") {
							console.log("Child found");
							dialog.remove();
							document.querySelector(".ui-widget-overlay").remove();
							console.log("Elements removed");
						}
					}
					document.querySelector("#tempStyleUntilFix").remove();
				}, 1500);
			});
		</script>
	';
}

So what happends all .ui-dialog pop ups get hidden immidiately. Then it checks for a .ui-dialog container with “Access Denied”. If it exists, then remove it from the HTML. And then remove the div containing the css (because you don’t want ALL the .ui-dialog alerts to be hidden, just the “Access Denied” one.

CSS takes place instantly and javascript takes place after 1500 miliseconds to allow ConcreteCMS plenty of time to generate the “Access Denied” error.

Again, not an official fix but a workaround until the issue gets patched.

10

@vassie98 @newmoon all right you’ve stumped me - can you both let me know the exact version of v8 you were on and your process to upgrade so I can recreate? E.g. did you go 8.3.1 → 9.1.3, or like 8.2.1 → 8.5.10 → 9.1.3? Etc.

And if you’ve got it, the PHP version(s) you were on, MySQL or MariaDB versions, and for good measure Linux version (or other operating system). Thx thx.

11

I’ve spoken with my system administrator and these were the steps he used to update the website

Edit composer.json

Changed the value of "concrete5/core": "^8.2" to "^9.1"

public/concrete/bin/concrete5 c5:info | grep "Version"

concrete5 Version

Core Version - 8.5.12

Version Installed - 8.5.12

Database Version - 20220319043123

Version - 10.5.18-MariaDB

PHP Version 7.4

composer update

Note: We also tried replacing the concrete directory in it’s entirety and then using composer update

Upgrading concrete5/core (8.5.12 => 9.1.3)

Copy DoctrineAnnotations.php from a working website to the one we’re trying to update. Because this file is missing after updating to Concrete 9.1.3

cp working_website/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php to_update_website/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php

Visiting the home page of the website to let the update go through

Logging in as admin in website.com/login

Now here is where things get tricky

My system administrator got the ‘Access Denied’ error after these steps:

Editing a block

Publish changes, error immediately starts upon every page visit when logged in as admin

However when I (programmer and not administrator) try to update I get the error immidiately after updating and logging in instead of publishing changes

I hope this information is of use in pinpointing this issue.

Regards

12

I’ve suddenly started getting this error message - when in edit mode, whenever I go to any page it shows the dialog ‘Access Denied’ and all the trace info as shown at the start of this thread, however this has only just started happening and it started when I turned on advanced permissions and then went through the process of giving a specific user edit block rights on a particular page.

Although I’ve removed the edit permissions to try and get back to how things were, the message continues to appear, although everything seems to work fine once I close it.

Is there a known problem or have I broken something?

I’ve put in the workaround posted by @vassie98 and now the message appears but is quickly closed.

My environment is…

# Concrete Version
Core Version - 9.1.3
Version Installed - 9.1.3
Database Version - 20220908074900

# Hostname
centos7.whm-secure.com

# Environment
production

# Database Information
Version: 10.3.39-MariaDB-cll-lve
SQL Mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

# Concrete Packages
Free Map (2.1.1), Mega Menu (2.0.3), Simple Gallery (2.1.0)

# Concrete Overrides
None

# Concrete Cache Settings
Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).

# Server Software
LiteSpeed

# Server API
litespeed

# PHP Version
8.0.28

# PHP Extensions
bz2, calendar, clos_ssa, Core, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, i360, iconv, imap, intl, json, libxml, litespeed, mbstring, mcrypt, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, readline, Reflection, session, shmop, SimpleXML, soap, sockets, SPL, sqlite3, standard, tokenizer, xml, xsl, zip, zlib

# PHP Settings
max_execution_time - 180
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 120
max_input_vars - 6000
max_multipart_body_parts - -1
memory_limit - 512M
post_max_size - 8M
upload_max_filesize - 40M
zend.exception_string_param_max_len - 15
mbstring.regex_retry_limit - 1000000
mbstring.regex_stack_limit - 100000
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
unserialize_max_depth - 4096
13

A colleague has discovered/created a .htaccess fix for this issue since nearly all our updated websites started failing with the permission denied error.

By editing your .htaccess to this below, the error disappeared completely.

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d+
RewriteCond %{REQUEST_METHOD} =GET
RewriteCond %{REQUEST_URI} !^/dashboard(.*)?
RewriteCond %{REQUEST_URI} !^/concrete(.*)?
RewriteRule ^(.*)/$ /$1 [L,R=301]
RewriteCond %{HTTPS} off
RewriteRule .*https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Hopefully happy coding from here on out!

14

Thanks for that, I’ll give it a try once I’ve got my head around it (the last 4 ines are fairly obvious but the rest - I can see what but just wonder why?!). It would be nice if ‘they’ found out why it was happening and fixed it!

The thing that’s confusing me is the ‘+’ on the first RewriteCond test. Can someone explain what that is doing?