[Building Sakai] Customizing rich-text sanitization in Sakai 2.8.x

[Noah Botimer]

Actually, I would not consider this a second rate option. I consider
it to be preferable and I just never got around to working up a decent
pattern to insert things like this (maybe as a meta plugin).

I did a quick proof of concept for dropping in YouTube videos (as divs
that are swapped out for iframes at render time), but never made it
production ready. It was simple and pretty elegant.

With a little work, the placeholders can have a nice little rendering
and context menu in the editor.

Thanks,
-Noah

> On Dec 2, 2013, at 8:16 PM, Branden Visser <mrvisser at gmail.com> wrote:
>
> Matthew, Noah, thanks for your replies. You've confirmed my fear which
> was that it would need some one-off changes to the Sakai source --
> antisamy is a fantastic addition for 2.9!
>
> In my context it is an FCK editor plugin, so I think rather than
> tossing an iframe into the rich text field, my best option appears to
> be to drop in a placeholder element with data, and swap in the iframe
> I need when the DOM is loaded. At least for pre-2.9 that seems to be
> the path of least resistance.
>
> Thanks again for your input!
>
> Cheers,
> Branden
>
>> On Mon, Dec 2, 2013 at 1:50 PM, Noah Botimer <botimer at umich.edu> wrote:
>> I did something along these lines to allow data-* attributes in KNL-1007...
>> Let's just say that it was a bit of a challenge, but that was kind of
>> changing the grammar to allow wildcard attributes.
>>
>> It would be somewhat more direct to filter the attribute values. There is a
>> checkValue method that is used to scan SVG data -- I think you can probably
>> extend that to scrub iframes (in combination with the config bits Matt
>> mentions).
>>
>> http://source.sakaiproject.org/viewsvn/kernel/branches/kernel-1.2.x/kernel-util/src/main/java/org/sakaiproject/util/FormattedText.java?view=markup#l917
>>
>> Thanks,
>> -Noah
>>
>>
>> On Dec 2, 2013, at 11:12 AM, Matthew Jones wrote:
>>
>> Not sure, in the old text processor we just allowed good and bad tags, there
>> was no care about the contents of the attributes (as long as they didn't
>> contain any script).
>>
>> It seems like you'd have to write a decent amount of custom code in
>> checkAttributes in the old FormattedText or do something about the
>> M_goodAttributePatterns. Maybe like remove the src parameter from a the
>> goodAttributes and process it separately with your list of urls? (If this is
>> what you're thinking) The biggest problem with this in 2.8 the kernel-utils
>> were packaged with every tool, so if you did change this you'd have to
>> rebuild your entire system to make sure every tool got the change.
>>
>> I haven't heard of anyone backporting Antisamy, with Antisamy what you're
>> describing is super easy. :(
>>
>>
>>
>>> On Mon, Dec 2, 2013 at 8:45 AM, Branden Visser <mrvisser at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> I was wondering what would be the best way to customize how rich-text
>>> content is sanitized in Sakai 2.8.x? I know antisamy was introduced in
>>> 2.9.x, but AFAIK this has not been back ported to 2.8 [1].
>>>
>>> Particularly, I would like to allow iframes whose src matches a
>>> particular regex (which antisamy allows).
>>>
>>> Any advice would be greatly appreciated!
>>>
>>> Cheers,
>>> Branden
>>>
>>>
>>> [1] https://jira.sakaiproject.org/browse/KNL-1015
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>>
>>