Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Sightly Filters, Plugins, & Extensions

Avatar

Level 1

The java API exposed by the sightly engine is fairly limiting (probably on purpose) but there are definitely going to be use cases to extend or override out-of-box behavior. Some immediate ones come to mind:

- sightly XSSFIlter & XSSExtension leverages the XSSAPI#formatHtml which relies on XSSFilter -- there is no sightly @ context which allows for custom ProtectionContext or antisamy policy file with the exception of 'unsafe' and manually XSSFilter scrubbing. Allowing extension/customization of sightly contexts might go a long way in providing an idiomatic means to use custom antisamy policy files without resorting to JSP.

- sightly AttributePlugin (data-sly-attribute)  blacklists 'style' and 'on___' attributes without documenting it or providing a means to disable. data-sly-<plugin> in general are great candidates for runtime configurability and extension.

- sightly Extension Registry Service could support & coordinate a priority property similar to how sightly FilterComponents do, which would make the RuntimeExtension API more useful, & avoid non-deterministic behavior and key collisions for RuntimeExtension#name()

 

Is there a future with sightly opening the doors to developers? This would help adoption and clean up our mixed JSP/sightly code bases.

1 Reply

Avatar

Level 1

Sorry, I had neglected to mention the well-documented tag whitelist for XSSExtension; this looks like a great candidate for configurability and extensibility as HTML undergoes revisions.