[JBoss JIRA] (WFLY-7018) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final
by Arnie Morein (JIRA)
[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ]
Arnie Morein commented on WFLY-7018:
------------------------------------
I upgraded ironjacamar to 1.4.0 in WF 10.1.0 and set up MySQL on another machine and the configuration worked.
> Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final
> -------------------------------------------------------------------
>
> Key: WFLY-7018
> URL: https://issues.jboss.org/browse/WFLY-7018
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: Mark S
> Assignee: Lin Gao
> Fix For: 11.0.0.Alpha1
>
>
> My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section.
> The stacktrace points to here:
> * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb...
> * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a...
> h3. The work-around
> h3. Wildfly 10.1.0.Final Datasource configuration via CLI
> {code}
> # No parameter to set a connection property value.
> {code}
> h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml)
> Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}}
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:datasources:4.0">
> <datasources>
> <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS">
> <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url>
> <connection-property name="databaseName">myapp</connection-property>
> <driver>postgres</driver>
> <security>
> <user-name>myapp</user-name>
> <password>myapp</password>
> </security>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> </datasource>
> <drivers>
> <driver name="postgres" module="org.postgres">
> <driver-class>org.postgresql.Driver</driver-class>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class>
> </driver>
> </drivers>
> </datasources>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7018) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final
by Arnie Morein (JIRA)
[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ]
Arnie Morein commented on WFLY-7018:
------------------------------------
I should also show my driver configuration:
{code:java}
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
<driver name="mysql" module="com.mysql">
<datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource</datasource-class>
</driver>
<driver name="mysqlxa" module="com.mysql">
<xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
</driver>
</drivers>
{code}
> Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final
> -------------------------------------------------------------------
>
> Key: WFLY-7018
> URL: https://issues.jboss.org/browse/WFLY-7018
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: Mark S
> Assignee: Lin Gao
> Fix For: 11.0.0.Alpha1
>
>
> My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section.
> The stacktrace points to here:
> * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb...
> * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a...
> h3. The work-around
> h3. Wildfly 10.1.0.Final Datasource configuration via CLI
> {code}
> # No parameter to set a connection property value.
> {code}
> h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml)
> Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}}
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:datasources:4.0">
> <datasources>
> <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS">
> <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url>
> <connection-property name="databaseName">myapp</connection-property>
> <driver>postgres</driver>
> <security>
> <user-name>myapp</user-name>
> <password>myapp</password>
> </security>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> </datasource>
> <drivers>
> <driver name="postgres" module="org.postgres">
> <driver-class>org.postgresql.Driver</driver-class>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class>
> </driver>
> </drivers>
> </datasources>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7890) Unable to set IPv6 address in Elytron authentication context match-host rule
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7890?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7890:
-------------------------------
Description:
Setting IPv6 address in wildfly-config.xml cause validation error.
{code:xml|title=wildfly-config.xml}
<?xml version="1.0" encoding="UTF-8"?>
<authentication-client xmlns="urn:elytron:1.0">
<authentication-configurations>
<configuration name="set-host-to-localhost">
<set-host name="localhost"/>
</configuration>
</authentication-configurations>
<authentication-rules>
<rule use-configuration="set-host-to-localhost">
<match-host name="::1"/>
</rule>
</authentication-rules>
</authentication-client>
{code}
{code:title=server.log}
java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{code}
It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
[1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be5...
was:
Setting IPv6 address in wildfly-config.xml cause validation error.
{code:xml=wildfly-config.xml}
<?xml version="1.0" encoding="UTF-8"?>
<authentication-client xmlns="urn:elytron:1.0">
<authentication-configurations>
<configuration name="set-host-to-localhost">
<set-host name="localhost"/>
</configuration>
</authentication-configurations>
<authentication-rules>
<rule use-configuration="set-host-to-localhost">
<match-host name="::1"/>
</rule>
</authentication-rules>
</authentication-client>
{code}
{code:title=server.log}
java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{code}
It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
[1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be5...
> Unable to set IPv6 address in Elytron authentication context match-host rule
> ----------------------------------------------------------------------------
>
> Key: WFLY-7890
> URL: https://issues.jboss.org/browse/WFLY-7890
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
>
> Setting IPv6 address in wildfly-config.xml cause validation error.
> {code:xml|title=wildfly-config.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-configurations>
> <configuration name="set-host-to-localhost">
> <set-host name="localhost"/>
> </configuration>
> </authentication-configurations>
> <authentication-rules>
> <rule use-configuration="set-host-to-localhost">
> <match-host name="::1"/>
> </rule>
> </authentication-rules>
> </authentication-client>
> {code}
> {code:title=server.log}
> java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
> at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
> at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
> at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be5...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7890) Unable to set IPv6 address in Elytron authentication context match-host rule
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7890?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-8297 to WFLY-7890:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7890 (was: JBEAP-8297)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR10)
> Unable to set IPv6 address in Elytron authentication context match-host rule
> ----------------------------------------------------------------------------
>
> Key: WFLY-7890
> URL: https://issues.jboss.org/browse/WFLY-7890
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
>
> Setting IPv6 address in wildfly-config.xml cause validation error.
> {code:xml=wildfly-config.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-configurations>
> <configuration name="set-host-to-localhost">
> <set-host name="localhost"/>
> </configuration>
> </authentication-configurations>
> <authentication-rules>
> <rule use-configuration="set-host-to-localhost">
> <match-host name="::1"/>
> </rule>
> </authentication-rules>
> </authentication-client>
> {code}
> {code:title=server.log}
> java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
> at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
> at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
> at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be5...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-644:
------------------------------
Fix Version/s: 3.0.0.Alpha19
(was: 3.0.0.Alpha18)
> jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-644
> URL: https://issues.jboss.org/browse/WFCORE-644
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha19
>
>
> The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file.
> This is problematic when the JVM is running in FIPS mode.
> The cli throws the following exception on startup:
> $ ./bin/jboss-cli.sh
> org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89)
> at javax.net.ssl.SSLContext.init(SSLContext.java:283)
> at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537)
> ... 11 more
> It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file:
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11"
> JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFCORE-13:
-----------------------------
Fix Version/s: 3.0.0.Alpha19
(was: 3.0.0.Alpha18)
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Labels: EAP
> Fix For: 3.0.0.Alpha19
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1351:
-------------------------------
Fix Version/s: 3.0.0.Alpha19
(was: 3.0.0.Alpha18)
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 3.0.0.Alpha19
>
> Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1282:
-------------------------------
Fix Version/s: 3.0.0.Alpha19
(was: 3.0.0.Alpha18)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha19
>
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months