Conversation
raviks789
previously approved these changes
Apr 17, 2026
nilmerg
force-pushed
the
revert-form-element-escaping
branch
from
c29f888 to
33b3df7
Compare
Member
Author
|
|
raviks789
approved these changes
Apr 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It turned out to be rather problematic to implicitly escape every form element name as we cannot guarantee that element names are not programmatically constructed already.
Examples:
\ipl\Html\FormElement\CheckboxElementrenders a hidden element representing its unchecked state and usesgetValueOfNameAttributeto define the name for it. This is done to support fieldsets containing a checkbox element. Though, fieldsets require special element names and hence this results in an constructed name with brackets being used as literal and hence the hidden element escapes it.Another case is when an element with an escaped name is also capable of auto-submitting the form. Icinga Web will transmit the name of such an element in a special http request header value and since we used invisible control characters to escape form element names, this resulted in invalid header values.
--
It's for these reasons that we decided to drop support for implicit form element name escaping again and require form implementors to safe-guard themselves by explicitly escaping their names.
Form::escapeReservedChars()has been deprecated and triggers a deprecation notice if used from now on.