1.0 Problem/Motivation

When I have a form set to "block unknown users", a message is shown that they cannot access the form, but the form is still displayed. This is potentially confusing.

2.0 Detailed steps to reproduce (embed screenshots)

Create a webform with Civicrm integration, and tick "Block unknown users"

When accessing the form when logged out, the form will show with a message "Sorry, you do not have permission to access this form."

3.0 Proposed resolution

The form fields should not show when permission is not granted to access the form.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

nicholosophy created an issue. See original summary.

yakim made their first commit to this issue’s fork.

yakim’s picture

Status: Active » Needs review

Proposed enhancement to improve UX for anonymous users when "Block unknown users" is enabled

I’ve investigated this issue. While the originally reported behavior appears to be resolved in recent versions, I believe the current implementation can still be improved from a UX and access control standpoint.

Current behavior:
When "Block unknown users" is enabled in the Webform CiviCRM settings, and an anonymous user visits a page that embeds a webform (e.g., via a node), the entire page is blocked with the generic message:

"You are not authorized to access this page."

This happens even if:

  • The user has view access to the node.
  • The webform is publicly viewable,
  • The intention is only to block submission, not the entire route.

This behavior is due to an AccessDeniedHttpException() being thrown in
webform_civicrm/src/WebformCivicrmPreProcess.php, around this line:

if ($this->settings['block_unknown_users']) {
  $this->form['submitted']['#access'] = $this->form['actions']['#access'] = FALSE;
  throw new AccessDeniedHttpException();
}

Proposed enhancement:
Instead of denying access to the entire page (route), we can cleanly hide only the webform output by setting:

$this->form['#access'] = FALSE;

This preserves access to the rest of the page (e.g., node content) and aligns better with the principle of least surprise: users see what they’re allowed to, and only the form itself is hidden.

Benefits:

  • Prevents unnecessarily blocking access to the parent route.
  • Plays well with nodes/pages embedding webforms.
  • Provides a cleaner UX — users don’t hit an abrupt 403 if they're just browsing content.

As I do not have push access to the Git repository, I’ve submitted a merge request here:
🔗 MR #21 on git.drupalcode.org

@karing, please let me know if this change makes sense. I’d be happy to refine or adjust it if needed.

cc @colemanw

yakim’s picture

Version: 6.2.5 » 6.x-dev

Moved the fix to GitHub PR (per maintainer guidance to use GitHub for CI):
PR: https://github.com/colemanw/webform_civicrm/pull/1098
Target branch: 6.x
Reference MR: https://git.drupalcode.org/project/webform_civicrm/-/merge_requests/21

Summary:
When Block unknown users is enabled, anonymous users currently get a 403 for the entire page that embeds the form. This change hides only the embedded webform output instead, keeping the page accessible.

Tests:
GitHub Actions Integration Tests are awaiting maintainer approval to run (workflow awaiting approval).

karing’s picture

@nicholosophy - can you please check that this resolves the issue you originally reported?

yakim’s picture

Hi @karing,

Just following up on this issue after the MR was merged.

Since the fix has been merged and there have been no reported regressions or follow-up concerns for several months, I think it would be reasonable to consider this issue resolved unless the original reporter provides additional feedback.

To keep this moving, would it be okay to wait another 2 weeks for a response from the original reporter, and if there is no further feedback by then, treat the issue as resolved/closed and proceed with awarding the Drupal.org credits for the merged work?

Thanks again for reviewing and merging the fix.

karing’s picture

Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

karing’s picture

Thank you for following up. I've marked it as Fixed. And I'm 99% sure I got you credits for your work. If not - let me know [the new interface for assigning credits is quite different].

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.