Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Sightly Filters, Plugins, & Extensions


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


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.