Hello,
The HTL token with context="html" is stripping out certain HTML attributes. When XSS protection is turned off (context="unsafe"), the HTML renders as I originally expected. The following attributes are getting stripped: data, placeholder, pattern, minlength, required, and aria-*
- - - THE QUESTION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Is there a way to whitelist one or more of those attributes somewhere so that context="html" does not remove them on render? If there is not a way to whitelist them, what would you recommend aside from changing context to unsafe?
- - - ENVIRONMENT - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
We're using AEM 6.2 in Classic.
- - - SIMPLIFIED EXAMPLE BEGIN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
In the JS Use-api, the HTML element is defined and returned
var domFragment = '<input type="tel" id="phone" name="phone" class="helloworld" placeholder="Your phone" pattern="[0-9]*" minlength="16" maxlength="16" required aria-required="true" aria-labelledby="phone-lbl">';
return {
htmlForm: domFragment
}
In the HTML page, the token is set as:
<sly data-sly-use.form="formbuilder.js"></sly>
<div class="form-builder">
<form>
${form.htmlForm @ context='html'}
</form>
</div>
---Expected Output (and also what I see when I change the token to context="unsafe")---
<div class="built-form">
<form>
<input type="tel" id="phone" name="phone" class="helloworld" placeholder="Your phone" pattern="[0-9]*" minlength="16" maxlength="16" required aria-required="true" aria-labelledby="phone-lbl">
</form>
</div>
---Actual Output (with context="html")---
<div class="built-form">
<form>
<input type="tel" id="phone" name="phone" class="helloworld" maxlength="16">
</form>
</div>
- - - END - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
In application, I am generating an entire HTML form from JSON data in the SSJS and returning the built-form to ${form.htmlForm @ context='html'}. So adding all of these fields after generating it on the serverside would be 1) Awkward, and 2) Cumbersome.
Thank you for your <input>.
Solved! Go to Solution.
You can overlay /libs/cq/xssprotection/config.xml to /apps and add your attributes in the config. You can look at XSS Filter issue with the target attribute of the a tag
You can overlay /libs/cq/xssprotection/config.xml to /apps and add your attributes in the config. You can look at XSS Filter issue with the target attribute of the a tag
This was exactly what I was looking for. The included cross-post also helped demonstrate the execution of your solution. I had looked for something like that before posting here, but missed that one. Well done! Thank you!
Views
Replies
Total Likes
Views
Likes
Replies