klonos
commented
6 years ago ...assigning to you @quicksketch. The respective issue in d.org was filed back in 2012, so not sure how relevant all this is in Backdrop(?).
Any other thoughts/ideas after all this time?
This is related to #1032 and the respective issue for https://www.drupal.org/project/drupal/issues/1835188
Problem/Motivation In #1032, we're trying to improve the UI for configuring a text format. One of the most confusing parts of configuring a filter is figuring out the "Filter order" options. To new users, the filter order is baffling. Even experienced users sometimes need to grok code or parse through several modules' README.txt files to figure out the proper order for things.
Proposed resolution Research and evaluate ways that we can make filter order more predictable for contributed modules to be "secure by default". Right now modules are able to provide a default weight for their filter, but that default is completely worthless once a user has rearranged the filters on a text format and then enables a new filter. After increasing the security of filters by default, consider reducing the prominence of the filter order, such as relegating it to a vertical tab, collapsed fieldset, or another approach.
The idea is to improve the security of filtering is three-fold:
1) DO NOT ALLOW the
filter_htmlfilter to be disabled. It's always on and we remove the checkbox to disable it. However... you are able to configure the filter to allow all possible HTML tags, as well as a checkbox to disable the protection of event attributes, script src attributes, and style attributes. It's always been considered "best practice" to provide extensive tag lists rather than using the "Full HTML" format anyway. Forcing the filter to be on enforces this best practice and will encourage the user to add tags a-la-carte, rather than just disabling thefilter_htmlfilter.2) Give the
filter_htmlfilter a CONSISTENT WEIGHT. For example, a weight of "0". The manual order of the filter_html filter is still exposed to the user, but its weight will always be 0. Filters above thefilter_htmlfilter are given negative weights, filters places below it are given positive ones. This allows contributed modules to have a predictable target for the main security filtering to be done, so they can position themselves properly by default, though the user can still override this ordering.3) Make the
filter_htmlfilter (or potentially all filters) extensible and alterable. This will allow all security filters that should be run at the same time to have a predictable location. Modules such as WYSIWYG filter could amend or replace thefilter_htmlbehavior, rather than providing an entirely different filter. Within the multiple phases of thefilter_htmlfilter, modules could provide a code-only or hidden option to control their weight, as the number of filters that need to be run at this level should be minimal and be able to work together to find suitable weights (similar to the'weight'in D7's system table orhook_hook_registry_alter()).All of this is to say that the
filter_htmlfilter becomes the Grand Daddy of crucial security settings, allowing contrib modules to predictably compare themselves against a reliable target.Remaining tasks Brainstorm, discuss, implement.
User interface changes Reduce the prominence of filter order if we can ensure security by default.