[jira] [Updated] (SLING-4365) Streamline ESAPI configuration
[ https://issues.apache.org/jira/browse/SLING-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-4365: --- Fix Version/s: (was: 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 > > 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)
[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)
[jira] [Updated] (SLING-4365) Streamline ESAPI configuration
[ 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)
[jira] [Updated] (SLING-4365) Streamline ESAPI configuration
[ 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.6) XSS Protection API 1.0.8 > 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.8 > > > 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)
[jira] [Updated] (SLING-4365) Streamline ESAPI configuration
[ https://issues.apache.org/jira/browse/SLING-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Cotescu updated SLING-4365: Affects Version/s: XSS Protection API 1.0.0 > 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.6 > > > 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)
[jira] [Updated] (SLING-4365) Streamline ESAPI configuration
[ 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.4) XSS Protection API 1.0.6 > Streamline ESAPI configuration > -- > > Key: SLING-4365 > URL: https://issues.apache.org/jira/browse/SLING-4365 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Felix Meschberger > Fix For: XSS Protection API 1.0.6 > > > 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)
[jira] [Updated] (SLING-4365) Streamline ESAPI configuration
[ 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.2) XSS Protection API 1.0.4 > Streamline ESAPI configuration > -- > > Key: SLING-4365 > URL: https://issues.apache.org/jira/browse/SLING-4365 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Felix Meschberger > Fix For: XSS Protection API 1.0.4 > > > 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)
[jira] [Updated] (SLING-4365) Streamline ESAPI configuration
[ 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.0) XSS Protection API 1.0.2 > Streamline ESAPI configuration > -- > > Key: SLING-4365 > URL: https://issues.apache.org/jira/browse/SLING-4365 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Felix Meschberger > Fix For: XSS Protection API 1.0.2 > > > 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)
