[JBoss JIRA] (SECURITY-750) Database*LoginModules should use the transactionManagerJndiName module option
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-750?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-750:
--------------------------------------------------
Josef Cacek <jcacek(a)redhat.com> changed the Status of [bug 901477|https://bugzilla.redhat.com/show_bug.cgi?id=901477] from POST to VERIFIED
> Database*LoginModules should use the transactionManagerJndiName module option
> -----------------------------------------------------------------------------
>
> Key: SECURITY-750
> URL: https://issues.jboss.org/browse/SECURITY-750
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_0_19.Final
>
>
> The DatabaseCertLoginModule and DatabaseServerLoginModule use for role search a routine from a class org.jboss.security.auth.spi.DbUtil. But there is a hardcoded reference to JNDI name for Transaction Manager lookup "java:/TransactionManager" - which is not valid in the EAP 6. The JNDI name should be provided as a parameter.
> The login module option "transactionManagerJndiName" is already implemented in the DatabaseServerLoginModule, but it should be also added to the DatabaseCertLoginModule.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-2589) ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-2589:
-----------------------------
Description:
This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing
was:This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2589
> URL: https://issues.jboss.org/browse/WFLY-2589
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-2589) ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-2589:
-----------------------------
Description: This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead. (was: This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming things that should be undefined get passed through with the default value instead.)
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2589
> URL: https://issues.jboss.org/browse/WFLY-2589
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
--
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
12 years, 1 month
[JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are not relayed.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1750?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1750:
---------------------------
Fix Version/s: 3.5
> RELAY2 : Address formats are not relayed.
> -----------------------------------------
>
> Key: JGRP-1750
> URL: https://issues.jboss.org/browse/JGRP-1750
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4.1
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID.
> This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side.
> Suggestions:
> - Making address format "relayable" ?
> - Using the same (or an extended format) AddressGenerator of site Channel
--
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
12 years, 1 month
[JBoss JIRA] (SECURITY-770) Support external password for keystore of PicketBoxVault implementation
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/SECURITY-770?page=com.atlassian.jira.plug... ]
Ivo Studensky updated SECURITY-770:
-----------------------------------
Attachment: SECURITY-770.patch
> Support external password for keystore of PicketBoxVault implementation
> -----------------------------------------------------------------------
>
> Key: SECURITY-770
> URL: https://issues.jboss.org/browse/SECURITY-770
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Attachments: SECURITY-770.patch
>
>
> At the moment, the default implementation of Vault supports masked keystore password only. It would be nice to add a facility for external keystore password too so that customers can either define an external command to get the password or define their own class which provides a password for the keystore.
--
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
12 years, 1 month
[JBoss JIRA] (SECURITY-770) Support external password for keystore of PicketBoxVault implementation
by Ivo Studensky (JIRA)
Ivo Studensky created SECURITY-770:
--------------------------------------
Summary: Support external password for keystore of PicketBoxVault implementation
Key: SECURITY-770
URL: https://issues.jboss.org/browse/SECURITY-770
Project: PicketBox
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JBossSX
Affects Versions: PicketBox_4_0_19.Final
Reporter: Ivo Studensky
Assignee: Ivo Studensky
At the moment, the default implementation of Vault supports masked keystore password only. It would be nice to add a facility for external keystore password too so that customers can either define an external command to get the password or define their own class which provides a password for the keystore.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-2574) CliArgumentsTestCase should not rely on java beeing on path
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-2574?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky resolved WFLY-2574.
-------------------------------------
Fix Version/s: 8.0.0.CR1
Resolution: Done
Fixed in the master.
> CliArgumentsTestCase should not rely on java beeing on path
> ------------------------------------------------------------
>
> Key: WFLY-2574
> URL: https://issues.jboss.org/browse/WFLY-2574
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI, Test Suite
> Affects Versions: 8.0.0.Beta1
> Reporter: Tomaz Cerar
> Assignee: Alexey Loubyansky
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> If there is no java on path tests fail with
> {noformat}
> java.lang.AssertionError: Failed to start CLI process: Cannot run program "java": error=2, No such file or directory
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.integration.management.cli.CliScriptTestBase.execute(CliScriptTestBase.java:108)
> at org.jboss.as.test.integration.management.cli.CliScriptTestBase.execute(CliScriptTestBase.java:73)
> at org.jboss.as.test.integration.management.cli.CliScriptTestBase.execute(CliScriptTestBase.java:69)
> at org.jboss.as.test.integration.management.cli.CliArgumentsTestCase.testConnectArgument(CliArgumentsTestCase.java:103)
> {noformat}
> Test should use JAVA_HOME env variable or java that ran "current" process
> without this fix it is really hard to properly test build with different JDKs as test will always use default java for executing commands instead of build provided/configured one
--
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
12 years, 1 month
[JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are not relayed.
by Karim AMMOUS (JIRA)
Karim AMMOUS created JGRP-1750:
----------------------------------
Summary: RELAY2 : Address formats are not relayed.
Key: JGRP-1750
URL: https://issues.jboss.org/browse/JGRP-1750
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.4.1
Reporter: Karim AMMOUS
Assignee: Bela Ban
When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID.
This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side.
Suggestions:
- Making address format "relayable" ?
- Using the same (or an extended format) AddressGenerator of site Channel
--
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
12 years, 1 month