Showing 404 (not found) rather than 403 (permission denied) on private forums/containers

I have same problem but I'm not using LoginToboggan: when an anonymous user attempts to access a forum node restricted to authenticated users, the user sees a "Page not found" instead of the "Access denied".

Please can anyone solve this?

Are we talking about accessing a forum or a forum node?

As always, please state the path that you're trying to access...

Hello Salvis,
I got the same problem, anonymous users trying to reach the forum get a 404 error instead of 403.
http://domain/?q=forums/forums-name
When trying to view a topic, I get a access denied with the login block so that works great.

The 'Page not Found' message appears when an anonymous user tries to access a private forum (http://domain/forums/container-name/forum-name) or private forum container (http://domain/forums/container-name). 'Access denied' shows correctly for the actual messages in any of the private forums (http://domain/forums/message).

I am receiving the same Page not Found for the containers or forums, and Access Denied for the actual private forum post.

I am having the same issue. Poked around in code but haven't identified the issue yet.

Updating title to be more accurate, as the issue has nothing to do with LoginToboggan, and that function should work as expected if the bug itself is fixed.

This will be difficult to accomplish, because the core forum.module is in charge of displaying the forum page. We use hook_query_term_access_alter() to not return any forums to core that the current user should not be able to access.

Unlike with nodes, core has no concept of having a term (forum) but not being allowed to access.

Attached is a patch reworking the way the access works at /forum and /forum/%forum_forum. It's still not ideal because of the limitations of the Taxonomy Term entity, but it will provide the correct response code to users.

The forum/%forum_forum path in the menu has been altered to give it a access callback that passes through to forum_access_access. The menu path /forum is more complicated, but using a preprocess hook to remove any forums the user does not have access to is a hacky work around. If anyone has any improvements, I'd be grateful.

Drupal didn't like my code style, and the previous patch also contains a logic fail that present forum content as access denied. Fixed.

404 is how Drupal is designed, but I've come to agree that 403 could be useful at times.
This would need to be a global option with a default of OFF.

Updated patch.

Those tests aren't related to this patch: the test coverage for the module doesn't seem to be up-to-date and gives all kinds of unrelated fails when setting up.

Logic fail in the last patch - 404 behaviour on /forum when 403 set and vice versa.

No interested reviewers?

I agree this problem still exists and yes, it's logically incorrect. At least there should be a setting like in the patch if 404 is a solution for anyone... But I guess 403 is the way to go. Perhaps the patch should even set it as default.

For me the patch works great, but I think this is too important for just a single manual review.

But I guess 403 is the way to go. Perhaps the patch should even set it as default.

I disagree. 403 is an information leak. The existence or non-existence of a certain forum (especially if it has a non-numeric path such as given by pathauto) is privileged information. Even if it has just a forum/TID path and you take away someone's access, then 403 will convey a different message than 404.

I see the willingness of some of you to spill this information for the benefit of being able to display the log-in block, but the setting must be clearly marked as a potential security issue. So, as a preliminary review:

+++ b/forum_access.admin.inc
@@ -502,6 +502,37 @@ function _forum_access_forum_troubleshooting_form($is_container, $has_interferen
+  $form = array(
+    'forum_access_behaviour' => array(
+      '#type' => 'select',
+      '#title' => t('Forum access behaviour override'),
+      '#description' => t('By default, Drupal returns a 404 Not Found error for forums a user does not have access to. Check this box to override this to return a 403 Access Denied'),
+      '#default_value' => variable_get('forum_access_behaviour', 0),
+      '#options' => array(
+        0 => t('Default behaviour (404)'),
+        1 => t('Override behaviour (403)'),
+      ),
+    ),
+  ) + $form;
+

Drupal standard is US English spelling, so please change "behaviour" to "behavior".

The text in the admin interface should be more explicit about what we're doing, something like (with radiobuttons):

Inaccessible forum behavior
(o) Return 404 Not Found (secure default)
(  ) Return 403 Access Denied to facilitate logging in
Change this only if disclosing the existence or non-existence of any given forum to the public is acceptable.

The italic codes should be non-translatable %variables. We want to be sure that nothing is lost in translation.

I'm on the fence about where to put the settings control. All other FA settings are on the admin/structure/forum/edit/forum/TID page in the "Access control" fieldset. I think I would prefer to have it there, between "Moderators" and "Module interference", with a note like "This is a global setting and applies to all forums." Let's discuss it...

+++ b/forum_access.module
@@ -68,6 +68,26 @@ function forum_access_menu_alter(&$items) {
+  if (variable_get('forum_access_behaviour', 0)) {

Use 404 and 403 as values.

We still need code-level reviews and testing, but I don't want to go first...

And, as usual, we'll need a D8 patch (with reviews and testing) to be committed before I can commit the D7 patch.

I would say this is a more universal problem than just forums, but the one module I can find that actually tries to solve it on a larger scale is https://www.drupal.org/project/m4032404 which has not seen a new release since august 2020...