You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Robert Munteanu (JIRA)" <ji...@apache.org> on 2016/08/04 09:13:20 UTC

[jira] [Updated] (SLING-4365) Streamline ESAPI configuration

     [ https://issues.apache.org/jira/browse/SLING-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Munteanu updated SLING-4365:
-----------------------------------
    Fix Version/s:     (was: XSS Protection API 1.0.10)
                   XSS Protection API 1.0.12

> 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.12
>
>
> 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)