December 2014 - jboss-jira - Jboss List Archives

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

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/SECURITY-871?page=com.atlassian.jira.plug... ] Derek Horton updated SECURITY-871: ---------------------------------- Git Pull Request: https://github.com/wildfly-security/jboss-negotiation/pull/20 > AdvancedLdapLoginModule should be able to retrieve password 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 > > AdvancedLdapLoginModule should be able to retrieve password from Vault -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Derek Horton (JIRA)

Derek Horton created SECURITY-871: ------------------------------------- Summary: AdvancedLdapLoginModule should be able to retrieve password 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 AdvancedLdapLoginModule should be able to retrieve password from Vault -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4149) NamingExceptions not properly handled in InitialContext

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4149?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4149: ----------------------------------------------- emartins(a)redhat.com changed the Status of [bug 1170359|https://bugzilla.redhat.com/show_bug.cgi?id=1170359] from NEW to ASSIGNED > NamingExceptions not properly handled in InitialContext > ------------------------------------------------------- > > Key: WFLY-4149 > URL: https://issues.jboss.org/browse/WFLY-4149 > Project: WildFly > Issue Type: Bug > Components: Naming > Reporter: David Lloyd > Assignee: Eduardo Martins > Fix For: 9.0.0.Beta1 > > > The change in https://github.com/jbossas/jboss-eap/commit/db525bf1d90a40eb909c8f915fca7... catches all Exception and rewraps them with NamingException. This behavior is undesirable if the original exception was already a NamingException. Catch and re-throw that exception type as-is before wrapping other exceptions. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4151) Spring Security with Active Directory Provider throwing Wrapped NamingException

by Bob Paulin (JIRA)

[ https://issues.jboss.org/browse/WFLY-4151?page=com.atlassian.jira.plugin.... ] Bob Paulin commented on WFLY-4151: ---------------------------------- Yes it is. Sorry for missing it. Closing. > Spring Security with Active Directory Provider throwing Wrapped NamingException > ------------------------------------------------------------------------------- > > Key: WFLY-4151 > URL: https://issues.jboss.org/browse/WFLY-4151 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.2.0.Final > Environment: Multiple > Reporter: Bob Paulin > Assignee: David Lloyd > > There is a bug logged against Spring Security for this issue as well https://jira.spring.io/browse/SEC-2754 > Providing the ActiveDirectoryLdapAuthenticationProvider with incorrect credentials causes internal server error when running on JBoss. > This is because ActiveDirectoryLdapAuthenticationProvider only considers top-level LdapExceptions, whereas JBoss seems to wrap exceptions thrown by InitialLdapContext into a top-level NamingException. > The issue does provide a suggested patch to spring security however I don't understand why Wildfly is wrapping the LdapExceptions when it did not appear to do this as late as JBoss EAP 6.2.0.GA -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4151) Spring Security with Active Directory Provider throwing Wrapped NamingException

by Bob Paulin (JIRA)

[ https://issues.jboss.org/browse/WFLY-4151?page=com.atlassian.jira.plugin.... ] Bob Paulin closed WFLY-4151. ---------------------------- > Spring Security with Active Directory Provider throwing Wrapped NamingException > ------------------------------------------------------------------------------- > > Key: WFLY-4151 > URL: https://issues.jboss.org/browse/WFLY-4151 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.2.0.Final > Environment: Multiple > Reporter: Bob Paulin > Assignee: David Lloyd > > There is a bug logged against Spring Security for this issue as well https://jira.spring.io/browse/SEC-2754 > Providing the ActiveDirectoryLdapAuthenticationProvider with incorrect credentials causes internal server error when running on JBoss. > This is because ActiveDirectoryLdapAuthenticationProvider only considers top-level LdapExceptions, whereas JBoss seems to wrap exceptions thrown by InitialLdapContext into a top-level NamingException. > The issue does provide a suggested patch to spring security however I don't understand why Wildfly is wrapping the LdapExceptions when it did not appear to do this as late as JBoss EAP 6.2.0.GA -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4149) NamingExceptions not properly handled in InitialContext

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4149?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4149: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1170359 > NamingExceptions not properly handled in InitialContext > ------------------------------------------------------- > > Key: WFLY-4149 > URL: https://issues.jboss.org/browse/WFLY-4149 > Project: WildFly > Issue Type: Bug > Components: Naming > Reporter: David Lloyd > Assignee: Eduardo Martins > Fix For: 9.0.0.Beta1 > > > The change in https://github.com/jbossas/jboss-eap/commit/db525bf1d90a40eb909c8f915fca7... catches all Exception and rewraps them with NamingException. This behavior is undesirable if the original exception was already a NamingException. Catch and re-throw that exception type as-is before wrapping other exceptions. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4151) Spring Security with Active Directory Provider throwing Wrapped NamingException

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-4151?page=com.atlassian.jira.plugin.... ] David Lloyd resolved WFLY-4151. ------------------------------- Resolution: Duplicate Issue I believe this is a duplicate of the problem described in WFLY-4149. > Spring Security with Active Directory Provider throwing Wrapped NamingException > ------------------------------------------------------------------------------- > > Key: WFLY-4151 > URL: https://issues.jboss.org/browse/WFLY-4151 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.2.0.Final > Environment: Multiple > Reporter: Bob Paulin > Assignee: David Lloyd > > There is a bug logged against Spring Security for this issue as well https://jira.spring.io/browse/SEC-2754 > Providing the ActiveDirectoryLdapAuthenticationProvider with incorrect credentials causes internal server error when running on JBoss. > This is because ActiveDirectoryLdapAuthenticationProvider only considers top-level LdapExceptions, whereas JBoss seems to wrap exceptions thrown by InitialLdapContext into a top-level NamingException. > The issue does provide a suggested patch to spring security however I don't understand why Wildfly is wrapping the LdapExceptions when it did not appear to do this as late as JBoss EAP 6.2.0.GA -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4151) Spring Security with Active Directory Provider throwing Wrapped NamingException

by Bob Paulin (JIRA)

Bob Paulin created WFLY-4151: -------------------------------- Summary: Spring Security with Active Directory Provider throwing Wrapped NamingException Key: WFLY-4151 URL: https://issues.jboss.org/browse/WFLY-4151 Project: WildFly Issue Type: Bug Components: Naming Affects Versions: 8.2.0.Final Environment: Multiple Reporter: Bob Paulin Assignee: David Lloyd There is a bug logged against Spring Security for this issue as well https://jira.spring.io/browse/SEC-2754 Providing the ActiveDirectoryLdapAuthenticationProvider with incorrect credentials causes internal server error when running on JBoss. This is because ActiveDirectoryLdapAuthenticationProvider only considers top-level LdapExceptions, whereas JBoss seems to wrap exceptions thrown by InitialLdapContext into a top-level NamingException. The issue does provide a suggested patch to spring security however I don't understand why Wildfly is wrapping the LdapExceptions when it did not appear to do this as late as JBoss EAP 6.2.0.GA -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3519) process-id-uuid and related attribute should consider alternatives/required attributes in :write-attribute handler

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3519?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3519: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/7015 (was: https://github.com/wildfly/wildfly/pull/6403) > process-id-uuid and related attribute should consider alternatives/required attributes in :write-attribute handler > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-3519 > URL: https://issues.jboss.org/browse/WFLY-3519 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > The transaction subsystem causes the server fails to start (is halted) when just process-id-uuid is set to false without specifying the process-id-socket-binding. > When you run commands: > /subsystem=transactions:write-attribute(name=process-id-uuid,value=false) > :reload > Server fails with exception [1] > The transaction subsystem should block changes that causes the server would fail on reload. The user should get information that the process-id-socket-binding has to be set before reload could proceed, i.e., fail the reload operation. > [1] > 11:13:53,630 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:141) [jboss-as-controller-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10] > at org.jboss.as.server.ServerService.boot(ServerService.java:321) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:253) [jboss-as-controller-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[287,17] > Message: JBAS014723: Must include one of the following elements: SOCKET, UUID > at org.jboss.as.controller.parsing.ParseUtils.missingOneOf(ParseUtils.java:194) [jboss-as-controller-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10] > at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseProcessIdEnvironmentElement(TransactionSubsystem14Parser.java:390) > at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseCoreEnvironmentElement(TransactionSubsystem14Parser.java:340) > at org.jboss.as.txn.subsystem.TransactionSubsystem15Parser.readElement(TransactionSubsystem15Parser.java:59) > at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:110) > at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:53) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2] > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2] > at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1035) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10] > at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:469) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10] > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2] > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:133) [jboss-as-controller-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10] > ... 3 more > 11:13:53,635 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1899?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1899: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1168329|https://bugzilla.redhat.com/show_bug.cgi?id=1168329] from POST to MODIFIED > Discovery returns after 16 responses even if there are no coord responses > ------------------------------------------------------------------------- > > Key: JGRP-1899 > URL: https://issues.jboss.org/browse/JGRP-1899 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.2, 3.6.1 > > > Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. > This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. > h5. Solution > * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

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 December 2014