Remove AccessDeniedHttpException details from log messages

We ran into this as well, as the error came up in a situation where we thought there was a bug in our code. It wasn't clear to any of our developers that this was a normal condition for 403 and 404 responses.

What's challenging about this is that as a site owner, the word "Exception" usually means "something has gone wrong and code needs to be fixed", not "a request returned 403 or 404 but the site is working fine".

This also causes problems with monitoring tools like New Relic, because they will track all exceptions and not automatically ignore these as errors.

As is, the current log message isn't very helpful to users who aren't developers.

Instead of:

Path: /admin/content. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The 'access content overview' permission is required. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 118 of /var/www/html/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

I think a better message would be something like:

The user (name or anonymous) was denied access to (path) as they have not been granted the (permission) permission.

For reference, the logging occurs in core/lib/Drupal/Core/EventSubscriber/ExceptionLoggingSubscriber.php. It would be possible to alter or replace this subscriber.

Given that many sites will prefer to track 403s or 404s outside, I think it also makes sense for this to be possible to disable entirely. That way, we prevent log spam in Drupal in the case of crawlers hitting many 404s, letting external systems like Google Analytics or web server logs handle tracking those responses.

We're witnessing these log messages when accessing pages that don't explicitly grant access (i.e., access result is neutral), which seems like a bug to me.

Agree with @cilefen in #13:

I am a -1 on this idea because IMO, more information is always better.

but of course also see the other side.

So perhaps a contrib module could hook in and prevent logging this kind of errors for anyone who has an issue with that?

I don't know the issue is related or not. But i am geting the same log in Drupal commerce, while in the review page of a product checkout as:

Path: /checkout/49/review. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 118 of /code/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

and
User: Anonymous (not verified) . I don't get why the user is Anonymous because i am still logged in and i am making the order :) !

I am getting the same issue with users that are authenticated and until about three weeks ago had access to pages (all with correct permissions to display pages and menu items) but suddenly these pages are now unauthorised to the same users. Other strange permissions issues are showing up in Views that also previously worked fine for Users.

I am at my wits end trying to understand what has happened with the permissions and have checked all permissions and they are correct as designed.

Is this something to do with Drupal Core?

Any suggestions as to how to resolve this would be appreciated.

User 1 can still use the site as designed, just not users!

I get this too. My Config menu has disappeared, and when I manually go to admin/config, I get "access denied"
Path: /admin/config. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 115 of /home/myname/public_html/mysite/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).
I am admin. How do I track this down?

@tjtj your issue is different to the one reported here. You might have better luck in the #support channel on Drupal slack.

I agree these shouldn't be logged as exceptions, we should just extract the message instead.

Hi guys.

This issue may be bigger than it seems. Let me explain: I'm running a local version of Drupal 10.3.5, which is a mirror of a production version.

I've been noticing this type of message for a while now, but I hadn't worried about it yet.

Today, I was testing to add a block to an existing content type, but I couldn't add the block and when I checked the error log, I saw the following message:

The interesting thing is that, since it's a local version, only I was logged into the site, but the system is recognizing me as an anonymous user.

I've been noticing the same type of problem when accessing other parts of the site's administrative area and I think the problem is related to Cache and Permissions.

We're having the exact same issue astutonet just mentioned, except for us it's only happening on production (not staging or local using ddev). It is intermittent. We've ruled out anything on the Drupal side. Both that comment and mine aren't really related to this issue other than the fact that I at least agree that the error is too verbose when it's obviously just Anonymous trying to access something it doesn't have access to.

Does a generic 403 really need to capture such verbose data? My suggestion for this ticket is to make it configurable and off by default. If you really need it for dev/debug purposes, you would go to /admin/config/development/logging and enable it.

Also having the same issue. In a 24 hour period, a site that I manage had almost 14,000 logs of:

Channel: access denied
Level: WARNING
Message: Path: XXXX. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The 'view any unpublished content' permission is required. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 115 of /app/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).
UID: 0

While I'm sure this is expected behaviour in the code, I would suggest that User 0 would realistically never be given "view any unpublished content' permission, and as such, this isn't something worth logging as a Warning.

The user was provided the correct 403 page response, which is the expected behaviour for this interaction.

I would say that there is nothing to Warn about in this instance.

PaperTrail reports these as "emergencies" because an exception is generated. Exceptions usually result in a 500 error or in some way indicate that the code is incorrect. Having trouble understanding why a simple 403 response is along an expected permissions-based codepath generates an Exception. Is there a good reason not to handle this exception and log the 403 cleanly?

Hi all, a bit of an odd one here, but the issue being described here of the path and permission required to view a page being shown in the log message would actually be extremely useful to me right now... I’ve just installed the domain_access module and I'm also using the acb module, but unfortunately for some unknown reason to me every role on the site (accept administrator because they have the bypass permission) is unable to edit unpublished content and I’d like to know where and what exactly is causing this 403...

In my db log messages I'm just getting "Uncaught PHP Exception Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: "" at AccessAwareRouter.php line 115" which is obviously not ideal for my situation, i can see in the code of AccessAwareRouter an empty string will be given if $access_result isn’t an instance of AccessResultReasonInterface, does anyone have any idea of why this might be the case?

I’ve got webprofiler set up to try and figure out why the node edit pages of unpublished nodes are triggering this access denied but i haven’t been able to work it out from there. So does anyone have any tips for getting to the source of such a permission issue?

I was on 10.3.14 but then i downgraded to 10.3.5 when i saw @astutonet was on that version and seeing the missing permission but no dice for me.

@lincoln-batsirayi Try step debugging with Xdebug. Ideally configure it to break on exceptions. You can also try disable modules one by one to find a possible culprit. Sidenote: this kind of support question is somewhat out of scope of this issue, so you might take any follow-up questions elsewhere (eg #drupal-support in Slack). I'm still not really convinced that having an uncaught exception for a 403 ending up in logs is useful in this case either.