Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | filter.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
The 'Limit HTML Tags' filter currently does more than what its name implies ... it also strips "JavaScript event attributes, JavaScript URLs, and CSS."
That's assuming that I want to limit my users' HTML because of security reasons. Seems a non sequitur to me ... I understand that this filter is often used for security reasons, but that's not the only reason to use it.
Examples:
- I don't want my users posting content with h1 tags, because it will have search engine implications.
- I don't want to allow div tags because that eliminates the possibility that an unclosed div element will break my site layout.
- My users paste bad code from outside code generators, and disallowing font tags cleans up the code considerably.
I understand there are other ways to accomplish the above. (Although, there is no perfect solution since all HTML filters I've seen have their own hardcoded element whitelists because of similar security assumptions.) And obviously, the examples I gave carry the implication that I trust my users not to do anything worse than unintentional code mangling. This will be the case for many organizational sites, I think.
So why would I want to turn off the stripped attributes part of the filter? Because if I trust my users not to do malicious things with the style attribute, I'd like them to be able to use it to style things. In fact, WYSIWYG editors use the style attribute on spans to accomplish certain things.
I'm not saying that the attribute stripping isn't incredibly important from a security standpoint--it is, IF you don't trust your users in the first place.
It just seems to me that the HTML filter would be MUCH more versatile if its two functions (which in my mind are not completely related in the first place) were split into two separate filters. And (from the outside looking in, admittedly) it does not seem that this would be difficult to implement. In fact, it hurts to have to assign this under Drupal 8--while I think this issue is the result of a faulty assumption, I suppose it doesn't fit the definition of a bug.
Comments
#1
Thanks for taking the time to report this issue.
However, marking as duplicate of #205160: Allow more granular HTML filter options for HTML attributes, not just tags.
You can follow up on that issue to track its status instead. If any information from this issue is missing in the other issue, please make sure you provide it over there.