About 2 years back, I was able to place a Webform's Submit button in a Container whose visibility was determined by a Computed Twig's value (hidden from the Webform but exposed as a token). The result: a Submit button was never rendered. This was a slick security measure to prevent unauthorized access to forms with sensitive data. However, now that method doesn't work; the Submit button is fully rendered and is only hidden visually (thus highly hackable). In hindsight this is probably how Webform was intended to work all along.

I think I'll need to finally write a custom module to alter the Webform and prevent the Submit buttons from rendering based on the Computed Twig token value. But honestly I don't know where to start. I've watched with interest the high-level discussion at #3092634: Allow webform handlers to control element access and I wonder if it is relevant to what I'm trying to do.

Is there any documentation on how to alter a Webform to prevent an element from rendering based on a Webform Submission element value (exposed as a token)? If not, can this issue perhaps be the seed of that documentation?

Comments

nodecode created an issue. See original summary.

jrockowitz’s picture

jrockowitz commented

I think you might be able to create Webform Handler that blocks a form from being submitted with conditional logic.

This "block form submission" handler's conditional logic could mirror your submit buttons conditional logic.

BTW, even if you could get the conditional submit button to be removed from the HTML, instead of visually hidden, someone could hack the form and create a submit button which might still post the data to the server.

nodecode’s picture

nodecode commented

Yikes. Thank you for alerting me to that fact.

Is there a more secure approach to control access to a Webform via a user-entered value? I'm trying to limit access to a Webform attached to a node, where each node contains a hidden field value (a 'passphrase') that the user must type (or include as a query in the URL) to 'unlock' the attached Webform. Submissions are supposed to be allowed by anonymous users.

I'm frighteningly close to finishing this project and now I'm feeling a bit foolish.

jrockowitz’s picture

jrockowitz commented

Sounds like you should look at https://www.drupal.org/project/webform_authcode or https://www.drupal.org/project/protected_pages

nodecode’s picture

nodecode commented

Could we revisit your idea of a Webform Handler? My form is multi-step, so could a "block form submission" Webform Handler conceivably prevent a user from proceeding past the first page (i.e. nothing else is rendered but the first page)? That would work for me.

(P.S. I did review those modules above and the way they're implemented would not be practical for my situation due to the sheer volume of nodes my project would be processing on a daily basis, i.e. hand-typing passphrases is not an option).

jrockowitz’s picture

jrockowitz commented

You could create a very basic webform handler that uses \Drupal\webform\Plugin\WebformHandlerBase::validateForm to set a validation error that blocks a form being submitted. When you create an instance of the handler, you can define conditional logic which would only block the form if all the conditions are met.

nodecode’s picture

nodecode commented

I like this idea very much. I found a related guide How to add custom validation to a Webform element. I assume this is the process you're referring to?

jrockowitz’s picture

jrockowitz commented

Method #2 is a very good starting point.

jrockowitz’s picture

jrockowitz commented

We might be able to build a generic Webform Message handler that displays a message or validation error depending on the submission's state.

I take that thought back because the Action handler already supports displaying messages.

nodecode’s picture

nodecode commented

Man do I love the idea though. I can think of so many uses for a generic Validation error handler. Basically a validation error triggered on next/submit button click with a required message field (and possibly a required conditional if that makes any sense). That's essentially what I'm doing minus securing the rest of the form with a validation error.

On the other hand, the Action handler itself could conceivably be expanded to include "... when next/submit button pressed." and have a "Throw validation error" action. Maybe that makes more sense.

jrockowitz’s picture

jrockowitz commented

The Action handler is triggered via submission operations. This new handler should be triggered via form action which is why it should be dedicated handler that displays a message via form validation and maybe form submission.

nodecode’s picture

nodecode commented

So if I follow correctly, we're closing in on plans to generalize the Method #2 custom validator mentioned above. From what I can gather this will likely involve:

  1. Allowing the Form Validator Hander (or whatever it's called) to be used with any Webform (obviously)
  2. Replacing the FormState::setErrorByName function with FormState::setError and linking that function's message option with a user-editable text area in a new Form Validator Handler UI.
  3. Providing clear usage instruction in the handler's UI -- For example a message (rather than a requirement) that the 'Under normal circumstances you would use Conditions with this handler'; and an explanation that 'This handler triggers a form-wide submission error'.
jrockowitz’s picture

jrockowitz commented

#12 sounds right. Since this is an edge case handler, it should live in a dedicated contrib module.

jrockowitz’s picture

jrockowitz commented
Status: Active » Closed (outdated)