[
https://issues.apache.org/jira/browse/SLING-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-4365:
--------------------------------
Fix Version/s: (was: XSS Protection API 1.0.8)
XSS Protection API 1.0.10
> Streamline ESAPI configuration
> ------------------------------
>
> Key: SLING-4365
> URL: https://issues.apache.org/jira/browse/SLING-4365
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: XSS Protection API 1.0.0
> Reporter: Felix Meschberger
> Fix For: XSS Protection API 1.0.10
>
>
> Currently the ESAPI is configured using the DefaultSecurityConfiguration
> class. This configuration is configured such as to:
> * read configuration from various file system locations, e.g. the user's
> home folder
> * list the helper classes to be used
> * configure the checking
> * configure logging
> In our context and setup, we don't want to have different classes configured,
> we want logging to always go through SLF4J logging and we want to limit and
> control where the configuration is read from.
> This issues is about creating a custom SecurityConfiguration class :
> * read from defined locations, probably one in the repository and one
> embedded in the bundle as a fallback. For example using the same
> configuration file as embedded default as for Sling Initial Content
> installation in the repository.
> * always log to SLF4J, maybe requiring an SLF4J based ESAPI LogFactory
> implementation. As a fallback, Log4J or commons logging APIs could still be
> used through the existing *-to-SLF4J API bridges we use.
> * Only support configuration of validation patterns (hence all classes
> "statically" defined)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
