TinyMCE attributes getting stripped

[ethanresnick]

When we tell tinymce that, say, the valid_elements are "a,ul,li,ol,p", I think we inadvertently are telling it that no attributes are allowed on any of those tags (because, if attributes are allowed we're supposed to specify them as part of that valid_elements string). This is no good, since attributes (e.g. href on a) need to be supported.

Possible solutions:

1. On the frontend, specify a default set of allowed attributes for each tag, and build those attributes into the valid_elements string generated here.
2. Actually output from the API which attributes are valid for each element on each field, and have the frontend read that (as opposed to using defaults).

Option 2 is obviously safer, since option 1 would in theory allow bad input (like onclick attributes) that could be used for XSS. But option 2 is also more complex. Still, it may not be that much more complex, and if we're going to release this as a framework, we need it. So I could see an argument for implementing either one.

[maxdumas]

I think option 2 definitely is the way to go. Regarding how to have the API output that; perhaps we could just have the API output, as part of its allowedHtml validation element, the same syntax that TinyMCE uses? For example, a[href], This would mean that no additional work is required on the front-end, and it might make it simpler for you to just hard-code a select few attributes that are valid.

Of course to really prevent XSS you'll still have to make validators for that stuff in API, so if that syntax doesn't make your life easier then there's no point.

If we go full-out and keep everything completely separate, would this then imply that the allowedHtml validation element would look something like:

"allowedHtml": [
    {
        "tag": "a",
        "attributes": [ "href" ]
    }
]

I'm personally ok with that. If it's easy for you to generate, parsing that and turning it into TinyMCE's format isn't difficult at all.