[
https://issues.apache.org/jira/browse/SLING-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-4365.
-------------------------------------
Resolution: Won't Fix
> 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
> Priority: Major
>
> 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
(v8.20.10#820010)
