January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-871) AdvancedLdapLoginModule should be able to retrieve bindCredential from Vault

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-871?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-871: -------------------------------------------------- Josef Cacek <jcacek(a)redhat.com> changed the Status of [bug 1174871|https://bugzilla.redhat.com/show_bug.cgi?id=1174871] from ON_QA to VERIFIED > AdvancedLdapLoginModule should be able to retrieve bindCredential from Vault > ---------------------------------------------------------------------------- > > Key: SECURITY-871 > URL: https://issues.jboss.org/browse/SECURITY-871 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_6_Final > > > AdvancedLdapLoginModule should be able to retrieve bindCredential from Vault -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ] Radim Vansa edited comment on JGRP-1876 at 1/12/15 8:01 AM: ------------------------------------------------------------ I was able to create a reproducer (SplitMergeTest.java, in attachment) on 4 nodes (actually trying to reproduce another issue). According to logs, each MergeView has two more subgroups. was (Author: rvansa): I was able to create a reproducer on 4 nodes (actually trying to reproduce another issue). According to logs, each MergeView has two more subgroups. > MERGE3 : Strange number and content of subgroups > ------------------------------------------------ > > Key: JGRP-1876 > URL: https://issues.jboss.org/browse/JGRP-1876 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4.2 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Fix For: 3.5.1, 3.6, 3.6.2 > > Attachments: 4Subgroups.zip, DkeJgrpAddress.java, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt > > > Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). > The final mergeView is correct and contains 210 members. > Here is an extract of subviews: > {code} > INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] > 210 subgroups > [.... > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] > [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] > ....] > {code} > II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. > Example: > {code} > {A, B, C} => {A, B, C} and {C} => {A, B, C} > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ] Radim Vansa updated JGRP-1876: ------------------------------ Attachment: SplitMergeTest.java I was able to create a reproducer on 4 nodes (actually trying to reproduce another issue). According to logs, each MergeView has two more subgroups. > MERGE3 : Strange number and content of subgroups > ------------------------------------------------ > > Key: JGRP-1876 > URL: https://issues.jboss.org/browse/JGRP-1876 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4.2 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Fix For: 3.5.1, 3.6, 3.6.2 > > Attachments: 4Subgroups.zip, DkeJgrpAddress.java, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt > > > Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). > The final mergeView is correct and contains 210 members. > Here is an extract of subviews: > {code} > INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] > 210 subgroups > [.... > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] > [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] > ....] > {code} > II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. > Example: > {code} > {A, B, C} => {A, B, C} and {C} => {A, B, C} > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-455) Include additional sun.jdk dependencies

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-455?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-455: ------------------------------------------------ Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1172577|https://bugzilla.redhat.com/show_bug.cgi?id=1172577] from ON_QA to VERIFIED > Include additional sun.jdk dependencies > ---------------------------------------- > > Key: WFCORE-455 > URL: https://issues.jboss.org/browse/WFCORE-455 > Project: WildFly Core > Issue Type: Bug > Components: Modules > Affects Versions: 1.0.0.Alpha14 > Reporter: Mustafa Musaji > Assignee: David Lloyd > > Include the following out of the box for sun.jdk module > - for working with javax.sql.rowset.RowSetProvider > <path name="com/sun/rowset"/> > <path name="com/sun/rowset/providers"/> > - for working with java.lang.invoke.MethodHandleProxies > <path name="sun/invoke"/> > This affects EAP customers using CP releases when overlays override changes made in the original module.xml. For sun.jdk classes, the above packages should be included out of the box. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4238) Vault script not showing shared key

by Abhinav Gupta (JIRA)

[ https://issues.jboss.org/browse/WFLY-4238?page=com.atlassian.jira.plugin.... ] Abhinav Gupta commented on WFLY-4238: ------------------------------------- Many Thanks [~pskopek] . Its working now without shared key. Please close this bug once documentation is updated. > Vault script not showing shared key > ----------------------------------- > > Key: WFLY-4238 > URL: https://issues.jboss.org/browse/WFLY-4238 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.1.0.Final > Environment: Windows 7 with jdk1.7.0_51 > Reporter: Abhinav Gupta > Assignee: Peter Skopek > > Team, > while using vault.bat , we are not able to see shared key. For every password entered I get a key as : VAULT::test1::pas::1 > Below is console for vault.bat > Microsoft Windows [Version 6.1.7601] > Copyright (c) 2009 Microsoft Corporation. All rights reserved. > D:\e3c\E3C_Install_ZipTask_SCE_B3\sw\System\WildFly\bin>vault.bat > ========================================================================= > JBoss Vault Tool > JBOSS_HOME: "D:\e3c\E3C_Install_ZipTask_SCE_B3\sw\System\WildFly" > JAVA: "C:\jdk1.7.0_51\bin\java" > JAVA_OPTS: "" > ========================================================================= > ********************************** > **** JBoss Vault *************** > ********************************** > Please enter a Digit:: 0: Start Interactive Session 1: Remove Interactive Session 2: Exit > 0 > Starting an interactive session > Enter directory to store encrypted files:D:\e3c\E3C_Install_ZipTask_SCE_B3\sw\System\WildFly\vault > Enter Keystore URL:D:\e3c\E3C_Install_ZipTask_SCE_B3\sw\System\WildFly\vault\vault.keystore > Enter Keystore password: > Enter Keystore password again: > Values match > Enter 8 character salt:12345678 > Enter iteration count as a number (e.g.: 44):50 > Enter Keystore Alias:vault > Initializing Vault > Jan 12, 2015 1:03:22 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init > INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready > Vault Configuration in WildFly configuration file: > ******************************************** > ... > </extensions> > <vault> > <vault-option name="KEYSTORE_URL" value="D:\e3c\E3C_Install_ZipTask_SCE_B3\sw\System\WildFly\vault\vault.keystore"/> > <vault-option name="KEYSTORE_PASSWORD" value="MASK-InRT5Cuu6V"/> > <vault-option name="KEYSTORE_ALIAS" value="vault"/> > <vault-option name="SALT" value="12345678"/> > <vault-option name="ITERATION_COUNT" value="50"/> > <vault-option name="ENC_FILE_DIR" value="D:\e3c\E3C_Install_ZipTask_SCE_B3\sw\System\WildFly\vault\"/> > </vault><management> ... > ******************************************** > Vault is initialized and ready for use > Handshake with Vault complete > Please enter a Digit:: 0: Store a secured attribute 1: Check whether a secured attribute exists 2: Exit > 0 > Task: Store a secured attribute > Please enter secured attribute value (such as password): > Please enter secured attribute value (such as password) again: > Values match > Enter Vault Block:test1 > Enter Attribute Name:pas > Secured attribute value has been stored in Vault. > Please make note of the following: > ******************************************** > Vault Block:test1 > Attribute Name:pas > Configuration should be done as follows: > VAULT::test1::pas::1 > ******************************************** > Please enter a Digit:: 0: Store a secured attribute 1: Check whether a secured attribute exists 2: Exit -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on JGRP-1905: ------------------------------------ If this can be handled in Infinispan via a ResponseFilter, that would be ideal. I'll experiment with this today. > FORK: RPCs might block if fork channel or fork stack is not available > --------------------------------------------------------------------- > > Key: JGRP-1905 > URL: https://issues.jboss.org/browse/JGRP-1905 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 3.6.2 > > > When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out. > h5. Solution > * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available"). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4237) Disabling weld in wildfly strangely degrad JSF performance

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4237?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-4237: ------------------------------ Affects Version/s: 8.2.0.Final Forum Reference: http://stackoverflow.com/questions/27508286/disabling-weld-in-wildfly-res... > Disabling weld in wildfly strangely degrad JSF performance > ---------------------------------------------------------- > > Key: WFLY-4237 > URL: https://issues.jboss.org/browse/WFLY-4237 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Environment: wildfly 8.2.0.Final > JSF 2.2 > Reporter: Mostafa Abdelkhalek > Attachments: weld_disabled.png, weld_enabled.png > > > The ajax response time dramatically increases by increasing the number of JSF components when weld is disabled. > This doesn't make sense and I have no idea why does it occur > *WELD ENABLED* > !weld_enabled.png|thumbnail! > *WELD DISABLED* > !weld_disabled.png|thumbnail! -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-866: --------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1173493, https://bugzilla.redhat.com/show_bug.cgi?id=1181086 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1173493) > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-868: --------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1173492, https://bugzilla.redhat.com/show_bug.cgi?id=1181084 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1173492) > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Beta3 > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-1905: ------------------------------------ Another option I see in Infinispan would be to attach a ResponseFilter to the request and only wait for a response from the nodes that are actually members of the "web" cluster. Actually it would be members of the individual caches, ATM we don't have a way to keep track of which members are part of a fork cluster. > FORK: RPCs might block if fork channel or fork stack is not available > --------------------------------------------------------------------- > > Key: JGRP-1905 > URL: https://issues.jboss.org/browse/JGRP-1905 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 3.6.2 > > > When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out. > h5. Solution > * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available"). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015