6

Our client would like to disable the ability to add script tags to RTF fields for all users, or would like a configuration where this can be turned on/off at the environment and potentially, publication and user level.

If we went down the XSLT / schema route, this would be a nightmare to implement and switch on/off, plus if we needed to upgrade later on &c.

Other solutions I can think of are:

  • CMS GUI extension that checks the ‘on-save’ of the component
  • CMS event system – again checking the ‘on-save’ of the component
  • Globally by modifying the ootb default XSLT (I need to research that one a bit)

Just wondering if anyone has also had to implement something similar and had some advice / gotchas that I need to consider.

Thanks

John

Improve this question

2 Answers 2

Reset to default
5

Valid and well known issue, I wondered when it would end up here... But I have to confess I haven't seen a good solution for it either yet. Personally I sticked with the Schema XSLT nightmare route. Kept a single Filtering XSLT which should be applied to all Format Area fields.

Looking at your option list I'm wondering why I never picked the Event System, since that is one that appeals to me. I think that can be implemented rather cleanly keeping it simple and effective.

Only added benefit of a UI extension would be to be able to directly notify the user before he presses the Save & Close button (using the Initiated phase could be close enough, that still happens while the window is open). But I think the implementation is a lot less trivial than an Event System would be.

Last option I wouldn't suggest, I bet it's not a supported one so voids your warranty (might be wrong there if the default XSLT is user editable, it should mention that in there once you find it).

Improve this answer
3
4

For configurable RTF-related requirements consider:

  • Embedded schemas to make the XSLT filtering modular.
  • Flipping the requirement by restricting script by default with an XSLT filter that removes <script> tags.
    • Let only certain groups add script in RTF (or maybe just in "code" components) with embedded component presentations (content injection).
    • The code can exist outside the RTF but keep a reference (component link) or
    • Escape the markup for the script and leave it in the RTF
  • During publish "inject" the script or transform it back with template logic.

This gives you control without changing what's in the RTFs.

  • Fewer RTF and XSLT filters to maintain
  • Configuration by publication through TBBs and inheritance
  • Configuration based on user, group, or publication through authorization

Gotchas include script that modifies the RTF, making sure extensions work in XPM, and an event system approach might need "find and update" or synchronization features.

Improve this answer
2
  • 1
    hi alvin, i'm not sure i can even understand this - perhaps could you elaborate on this: "Flipping the requirement by restricting script by default. Only certain groups can add script in RTF (or maybe just in "code" components)." - how is that implementable ootb without extension ??
    – johnwinter
    Commented Apr 11, 2013 at 15:49
  • Using the same embedded schema everywhere with an XSLT filter that prevents script gives you a "default setup" that prevents script in RTF. Then you need to give only certain groups the ability to put in code--think "content injection" with a component link. Then "inject" the actual code during publish. I'll update the answer.
    – Alvin Reyes
    Commented Apr 13, 2013 at 4:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.