June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2198) Remote Naming throws the same exception for different causes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2198: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1014414|https://bugzilla.redhat.com/show_bug.cgi?id=1014414] from VERIFIED to CLOSED > Remote Naming throws the same exception for different causes > ------------------------------------------------------------ > > Key: WFLY-2198 > URL: https://issues.jboss.org/browse/WFLY-2198 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported. > We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. > If all the the servers specified are not not running: > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) > If one of the servers is running, but the client's username/password are incorrect > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3124) JXM PluggableMBeanServerImpl assumes RealmUser principal

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3124?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3124: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1082072|https://bugzilla.redhat.com/show_bug.cgi?id=1082072] from VERIFIED to CLOSED > JXM PluggableMBeanServerImpl assumes RealmUser principal > -------------------------------------------------------- > > Key: WFLY-3124 > URL: https://issues.jboss.org/browse/WFLY-3124 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX > Affects Versions: 8.0.0.Final > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Fix For: 8.1.0.CR1, 8.1.0.Final > > > JXM {{PluggableMBeanServerImpl$LogAction}} assumes that {{RealmUser}} principal is present when Subject is not null. This condition is not always met and results into following exception: > {noformat} > Caused by: java.util.NoSuchElementException > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) > at java.util.HashMap$KeyIterator.next(HashMap.java:960) > at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.getCallerUserId(PluggableMBeanServerImpl.java:1250) > at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1233) > at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1158) > at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331) > at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.queryNames(MBeanServerAuditLogRecordFormatter.java:170) > at org.jboss.as.jmx.PluggableMBeanServerImpl.queryNames(PluggableMBeanServerImpl.java:871) > at org.infinispan.jmx.JmxUtil.findJmxDomain(JmxUtil.java:127) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (JBWEB-282) Lack of synchronization in org.apache.catalina.security.SecurityUtil

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-282: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1050225|https://bugzilla.redhat.com/show_bug.cgi?id=1050225] from VERIFIED to CLOSED > Lack of synchronization in org.apache.catalina.security.SecurityUtil > -------------------------------------------------------------------- > > Key: JBWEB-282 > URL: https://issues.jboss.org/browse/JBWEB-282 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA > Environment: -JBoss EAP 6.1.1 > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > Fix For: JBossWeb-7.3.0.GA > > > The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat: > https://issues.apache.org/bugzilla/show_bug.cgi?id=50138 > objectCache now needs to be a ConcurrentHashMap given our multithreaded starts. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3048: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1069127|https://bugzilla.redhat.com/show_bug.cgi?id=1069127] from VERIFIED to CLOSED > "Local" authentication fails when LDAP is used for ManagementRealm > ------------------------------------------------------------------ > > Key: WFLY-3048 > URL: https://issues.jboss.org/browse/WFLY-3048 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Environment: Ubuntu 13.04, Xeon-based VPS > Reporter: Matt Jensen > Assignee: Darran Lofthouse > Fix For: 8.1.0.CR1, 8.1.0.Final > > > When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working. > I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows: > <security-realm name="ManagementRealm"> > <authentication> > <local default-user="$local" /> > <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false"> > ... > </ldap> > </authentication> > <authorization map-groups-to-roles="false"> > <ldap connection="..."> > ... > </ldap> > </authorization> > </security-realm> > I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command. > The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm. > If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password. > I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password. > The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up. > The documentation specifically mentions that <local/> should work along with <ldap/> here: > https://docs.jboss.org/author/display/WFLY8/Security+Realms -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (JBWEB-281) Inconsistent use of genStringAsCharArray.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-281: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1050225|https://bugzilla.redhat.com/show_bug.cgi?id=1050225] from VERIFIED to CLOSED > Inconsistent use of genStringAsCharArray. > ----------------------------------------- > > Key: JBWEB-281 > URL: https://issues.jboss.org/browse/JBWEB-281 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-7.2.1.GA > Environment: All environments. > Reporter: Jeremy Whiting > Assignee: Remy Maucherat > Fix For: JBossWeb-7.3.0.GA > > > The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled. > This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache. > Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2760) Intermittent failure of ExternalContextBindingTestCase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2760?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2760: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1054106|https://bugzilla.redhat.com/show_bug.cgi?id=1054106] from VERIFIED to CLOSED > Intermittent failure of ExternalContextBindingTestCase > ------------------------------------------------------- > > Key: WFLY-2760 > URL: https://issues.jboss.org/browse/WFLY-2760 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.CR1 > Reporter: Jan Martiska > Assignee: Jan Martiska > Priority: Minor > > The server setup task sometimes fails to start the ApacheDS server instance because for some reason, BouncyCastle security provider doesn't get registered (it is added through a maven dependency rather than added to the JDK). This leads to a "connection refused" error during the test when it is trying to connect to the LDAP instance. > It worked for us if we just programatically forced registration of the BouncyCastleProvider before the initialization of ApacheDS. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2997) AccessAuditContext domainUUID is not set when the domain-uuid header is set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2997?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2997: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1092213|https://bugzilla.redhat.com/show_bug.cgi?id=1092213] from VERIFIED to CLOSED > AccessAuditContext domainUUID is not set when the domain-uuid header is set > --------------------------------------------------------------------------- > > Key: WFLY-2997 > URL: https://issues.jboss.org/browse/WFLY-2997 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1, 8.1.0.Final > > > org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler creates a UUID and sets "operations-headers" => "domain-uuid" on the op, but it does not pass the same UUID to AccessAuditContext. The result is the log record has null in the domainUUID field but the operation headers part of the "ops" field shows the uuid. Confusing. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3016) Prevent NullPointerException in JDR CommandLineMain

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3016?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3016: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1069850|https://bugzilla.redhat.com/show_bug.cgi?id=1069850] from VERIFIED to CLOSED > Prevent NullPointerException in JDR CommandLineMain > --------------------------------------------------- > > Key: WFLY-3016 > URL: https://issues.jboss.org/browse/WFLY-3016 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JDR > Affects Versions: 8.0.0.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 8.1.0.CR1, 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3347) the recovery manager service is starting before the CMRResourceAdd is being processed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3347?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3347: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1091308|https://bugzilla.redhat.com/show_bug.cgi?id=1091308] from VERIFIED to CLOSED > the recovery manager service is starting before the CMRResourceAdd is being processed > ------------------------------------------------------------------------------------- > > Key: WFLY-3347 > URL: https://issues.jboss.org/browse/WFLY-3347 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Fix For: 9.0.0.Alpha1 > > > we need to set com.arjuna.ats.jta.common.JTAEnvironmentBean::setCommitMarkableResourceJNDINames before the recovery manager service is started -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2161) JBAS014356 exception not thrown for @Asyncronous EJB methods

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2161?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2161: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1060734|https://bugzilla.redhat.com/show_bug.cgi?id=1060734] from VERIFIED to CLOSED > JBAS014356 exception not thrown for @Asyncronous EJB methods > ------------------------------------------------------------ > > Key: WFLY-2161 > URL: https://issues.jboss.org/browse/WFLY-2161 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Alpha4 > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 8.0.0.CR1 > > > If you call an ejb method with default visibility (e.g. from a servlet in the same package), an EJBException with code JBAS014356 is thrown because the method is not public. > If the method is annotated with @Asynchronous and returns void, the exception is not seen because the interceptor from AsyncFutureInterceptorFactory is used before NotBusinessMethodInterceptor, the exception is thrown in the worker thread instead. > With a void return, the exception is silently dropped. With a Future<?> return, it will be set as the failure exception on the future rather than being thrown from the call. > As per the forum reference we need to check the spec, but the validity of the business method should probably be checked before the handoff to the worker thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2014