After some investigation, I found that starting with Symfony 6.0, the InputBag::get()
method now throws a BadRequestException
when attempting to retrieve non-scalar values. In our project, this affects the UserPasswordForm.php
file, where InputBag::get()
is used to retrieve the default value for the "name" field. When this exception occurs, it gets cached and displayed to all subsequent anonymous requests.
Symfony's documentation recommends using InputBag::all()
to retrieve arrays instead. While we arenβt expecting an array for "name" here, switching from get to all should prevent issues with this specific form. The root cause may be related to a broader query parameter caching issue between requests, but this change will safeguard us in this particular context.
Regarding security, this change looks safe. The RequestSanitizer
class handles potentially unsafe keys in query parameters by removing them from the request object.
Iβm attaching a patch with this adjustment for review.
I am using Drupal 10.3.5 and the error still occurs.
Steps to reproduce:
- Using anonymous user, on cold cache, visit "/user/password?name[%23post_render][0]=passthru"
- "A client error happened" error message appears, which is expected.
- Visit "/user/password" without any query parameters and confirm that "A client error happened" still appears.
Here is a patch with a fix.
As @erwinvb mentioned, the problem is that nested dialogs have the same data-drupal-selector attribute. Current patch adds also paragraph bundle to the attribute, to make it more unique. It will probably work for most cases, except when for some reason we have the same paragraph form opened in nested dialogs. This case will require each dialog to know how deep in the nesting level it is.
Current patch is a quick fix for the most people :)
I have the same need on a project, so here is the patch :)
Regarding #13 β¨ Add Preprocessor Loading for Suggestions Fixed , here is a patch that allows deeper pre-processing: https://www.drupal.org/project/preprocess/issues/3112575#comment-14882622 β¨ Deeper Preprocess Suggestions don't load without a Template or actual hook_preprocess RTBC
I came across the same need, and the solution seems pretty simple, just remove the check if such a template exists before pre-processing it. Maybe I didn't take into consideration some edge cases, will see later :)
Attaching a patch.