[JBoss JIRA] (JBJCA-1156) encrypted datasource security , big performence hit.
by John L (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1156?page=com.atlassian.jira.plugin... ]
John L commented on JBJCA-1156:
-------------------------------
A complete pool definition we are using:
<datasource jta="false" jndi-name="java:/SomeDS"
pool-name="SomeDS" enabled="true" use-java-context="true" xmlns="urn:jboss:domain:datasources:1.1">
<connection-url>jdbc:jtds:sqlserver://localhost:1433/Some
</connection-url>
<driver>jtds</driver>
<new-connection-sql>select 1</new-connection-sql>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<pool>
<min-pool-size>1</min-pool-size>
<max-pool-size>100</max-pool-size>
<prefill>false</prefill>
<use-strict-min>false</use-strict-min>
</pool>
<security>
<security-domain>some-encrypted-ds</security-domain>
</security>
</datasource>
<security-domain name="some-encrypted-ds" cache-type="default">
<authentication>
<login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
<module-option name="username" value="some"/>
<module-option name="password" value="34959585858585"/>
</login-module>
</authentication>
</security-domain>
Every connection retrieved from datasource via jndi lookup from pool
decrypts the password using blowfish even though the connection is already connected to db.
The blowfish decrypts adds up to a large performance hit.
> encrypted datasource security , big performence hit.
> ----------------------------------------------------
>
> Key: JBJCA-1156
> URL: https://issues.jboss.org/browse/JBJCA-1156
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.0.12.Final
> Environment: using jboss 7.1.1 or jboss 7.1.3
> Reporter: John L
> Assignee: Jesper Pedersen
>
> We setup our jboss7.1.3 to use encrypted datasource passwords:
> <datasources>
> <datasource jndi-name="java:/SomDS" pool-name="SomeDS" enabled="true" use-java-context="true">
> .....
> <security>
> <security-domain>some-encrypted-ds</security-domain>
> </security>
> </datasource>
>
> ...
> <security-domain name="some-encrypted-ds" cache-type="default">
> <authentication>
> <login-module code="org.picketbox.datasource.security.SecureIdentityLoginModule" flag="required">
> <module-option name="username" value="some"/>
> <module-option name="password" value="-......."/>
> </login-module>
> </authentication>
> </security-domain>
> By using this our system took a 30% performance hit.
> Some transactions might call getConnection 50 times.
> It seems from looking at code that even if a connection already exists in the pool the password is
> decrypted on every call to get a connection from the datasource.
> Seems like it should only decrypt when a new connection is created to the database.
> Moving back to unencrypted passwords solves the performance problem.
> That is using:
> <security xmlns="urn:jboss:domain:datasources:1.1">
> <user-name>xxx</user-name>
> <password>yyy</password>
> </security>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2897) Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III commented on WFLY-2897:
------------------------------------------
Hmm... couldn't the JSF subsystem tell that the path is coming from a deployment and not from a core module? Just a thought. I never like to suggest using path logic to fix issues like this, but it's just a thought that came to mind. It should be possible to use ClassLoader logic; however, that might be a little bit safer I suppose. This is just an unfortunate problem, but perhaps the easiest solution is to make sure that google can find good information about this error :)
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2897
> URL: https://issues.jboss.org/browse/WFLY-2897
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Lincoln Baxter III
> Assignee: Farah Juma
> Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2897) Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III commented on WFLY-2897:
------------------------------------------
Hmm... couldn't the JSF subsystem tell that the path is coming from a
deployment and not from a core module? Just a thought. I never like to
suggest using path logic to fix issues like this, but it's just a thought
that came to mind. It should be possible to use ClassLoader logic; however,
that might be a little bit safer I suppose. This is just an unfortunate
problem, but perhaps the easiest solution is to make sure that google can
find good information about this error :)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2897
> URL: https://issues.jboss.org/browse/WFLY-2897
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Lincoln Baxter III
> Assignee: Farah Juma
> Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-922) <vault> does not have module option
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-922?page=com.atlassian.jira.plugin.s... ]
Kabir Khan resolved WFLY-922.
-----------------------------
Resolution: Duplicate Issue
Replaced by WFLY-3118
> <vault> does not have module option
> -----------------------------------
>
> Key: WFLY-922
> URL: https://issues.jboss.org/browse/WFLY-922
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: James Livingston
> Assignee: Peter Skopek
>
> The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
> The <vault> element should take a module option too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2897) Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-2897:
----------------------------------
For versions of JSF other than JSF 2.2.x, accidentally including a JSF implementation in the WAR file won't cause issues and WildFly's default JSF implementation will be the one that's used. It seems that this error only occurs when accidentally including JSF 2.2.x in the WAR file. WildFly's default JSF implementation will still be the one that's used but the error seems to occur when FaceletTaglibConfigProcessor attempts to process the facelets_jsf_core.taglib.xml file from the JSF JAR in the application's WEB-INF/lib directory:
{code}
2014-03-17 17:05:10,140 FINE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Processing facelet-taglibrary document: 'vfs:/content/sample-1.0-SNAPSHOT.war/WEB-INF/lib/javax.faces-2.2.2.jar/com/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml'
2014-03-17 17:05:10,141 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
{code}
The above log message does indicate that a JSF implementation has been included in the WAR file (it references 'vfs:/content/sample-1.0-SNAPSHOT.war/WEB-INF/lib/javax.faces-2.2.2.jar/com/sun/faces/metadata/taglib/facelets_jsf_core.taglib.xml'). It doesn't look like there's much that can be done in terms of additional error messages in this case since the JSF subsystem doesn't know that a WAR file includes a JSF implementation unless the WAR_BUNDLES_JSF_IMPL context param is specified.
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2897
> URL: https://issues.jboss.org/browse/WFLY-2897
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Lincoln Baxter III
> Assignee: Farah Juma
> Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2897) Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.... ]
Farah Juma closed WFLY-2897.
----------------------------
Resolution: Won't Fix
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2897
> URL: https://issues.jboss.org/browse/WFLY-2897
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Lincoln Baxter III
> Assignee: Farah Juma
> Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Dustin Minnich (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Dustin Minnich commented on WFLY-3033:
--------------------------------------
I want to be able to configure the Secure and HttpOnly attributes for JSESSIONIDSSO cookie.
> Better SSO configuration
> ------------------------
>
> Key: WFLY-3033
> URL: https://issues.jboss.org/browse/WFLY-3033
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Tin Tvrtkovic
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: single-sign-on, undertow
> Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (SECURITY-806) SecurityVaultFactory caching problems
by Kabir Khan (JIRA)
Kabir Khan created SECURITY-806:
-----------------------------------
Summary: SecurityVaultFactory caching problems
Key: SECURITY-806
URL: https://issues.jboss.org/browse/SECURITY-806
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossSX
Affects Versions: PicketBox_4_0_21.Beta1
Reporter: Kabir Khan
Assignee: Anil Saldhana
In WildFly we can define the vault at both the 'core' level, and within the security subsystem. The intent is that the user can specify different vaults in the two places, so say for the core one we go with
{code}
<vault/>
{code}
Now, in the security subsystem I want to use some other vault implementation so I do:
{code}
<vault code="my.custom.Vault"/>
{code}
Assuming the core stuff gets loaded first, that will return the 'default' vault, which gets cached, and which will also be returned for the 'custom' one I want in the security subsystem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2881) org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2881?page=com.atlassian.jira.plugin.... ]
Eduardo Martins reassigned WFLY-2881:
-------------------------------------
Assignee: Eduardo Martins (was: Tomaz Cerar)
> org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
> --------------------------------------------------------------------------------------
>
> Key: WFLY-2881
> URL: https://issues.jboss.org/browse/WFLY-2881
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Frank Langelage
> Assignee: Eduardo Martins
> Attachments: org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.txt, TEST-org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.xml
>
>
> Running build with smoke tests on current github sources I get failure in this test case.
> HOUR_OF_DAY is not 0 as expected but 1.
> I changed the Assert in the test case to print out firstTimeout.toString() instead of only timeZoneDisplayName.
> See attached files for more.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months