Introduce config.disallowedContent

[Piotrek Koszuliński]

We have config.allowedContent being a whitelist.

But real life cases often require also being able to define blacklist. Therefore we should introduce config.disallowedContent.

[Wiktor Walc]

Few things:

1. What will happen if both allowedContent and disallowedContent are defined in plugin definitions?

Example 1: allowedContent: a img strong disallowedContent: script iframe img

Example 2: allowedContent: img[*](*) disallowedContent: img(width, height)

1a) Will CKEditor accept anything that is accepted by allowedContent(s) and not disallowed by disallowedContent(s)?

This way a naive plugin would not be able to specify disallowedContent to quickly specify a set of tags that can be inserted by it (e.g. an "insert embed media" plugin that wants to inject video, audio, embed, object, param, iframe and such things), because allowedContent(s) will not allow it anyway.

1b) Will allowedContent be ignored totally if at least one disallowedContent rule is set? I cannot find any reasonable rule for disallowedContent that could explain such behavior. Besides it means that black listing is preferred over white listing...

2. what will happen with allowedContent and disallowedContent specified by plugins when the following options are set in config.js:

• config.allowedContent=true
• config.disallowedContent=true
• config.allowedContent rules are set
• config.disallowedContent rules are set
• config.allowedContent=true AND config.disallowedContent rules are set
• config.disallowedContent=true AND config.allowedContent rules are set

My opinion is that introducing config.disallowedContent will just increase the complexity of ACF. If we have so far just one real use case for it (blacklisting style and on* attributes), instead of supporting it "officially" in API let's just find a workaround for this particular issue.

[Wim Leers]

This, or something like it, is (AFAICT) necessary for ​https://drupal.org/node/1936392. I discussed this in that context with @Reinmar on March 27, I think slightly before this ticket was created.

---

Thinking purely conceptually and logically, I think there might be a case to be made for "whitelisting only" from a WYSIWYG editor perspective.

Having only a whitelist, you must enumerate all allowed tags, attributes, styles and classes. That might seem like more work, but this also ensures that you fully define the universe of all possible uses and values. For example, rather han being able to exclude (blacklist) e.g. just the target attribute on <a> tags, you'll have to allow (whitelist) all of the attributes you want to allow: href, hreflang and rel. More work, but also more certainty, more control. It's probably worth it.

Since a WYSIWYG editor's job is to generate markup, and it's easy to abuse it (or plugins for it) to generate unwanted markup, it makes a lot of sense to demand that the whole universe of allowed values is well-defined.

So, whitelisting only, allowedContent only, makes sense for CKEditor.

---

Replying to wwalc:

I think disallowedContent may not be necessary, since there's not really a use case for blacklisting tags. But there is a clear use case for blacklisting properties (attributes, styles, classes). What if CKEditor would just have to allow that?

Besides attributes and requiredAttributes, you could have forbiddenAttributes. In the string notation, you could use the ^ character for marking forbidden attributes, similarly like ! for required attributes. (Why ^? It could be another character of course, but ^ is used for negation in regular expressions.)