June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-795) AdvancedLdap login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-795: -------------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1065513|https://bugzilla.redhat.com/show_bug.cgi?id=1065513] from VERIFIED to CLOSED > AdvancedLdap login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-795 > URL: https://issues.jboss.org/browse/SECURITY-795 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Derek Horton > Fix For: Negotiation_2_2_7 > > Attachments: SECURITY-795.patch > > > AdvancedLdap login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2047) testConnection should account for deployment classloader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2047?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2047: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1007181|https://bugzilla.redhat.com/show_bug.cgi?id=1007181] from VERIFIED to CLOSED > testConnection should account for deployment classloader > -------------------------------------------------------- > > Key: WFLY-2047 > URL: https://issues.jboss.org/browse/WFLY-2047 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Alpha4 > Environment: All > Reporter: Jay Kumar SenSharma > Assignee: Stefano Maestri > Fix For: 9.0.0.CR1 > > > If a DataSource is created as following: > ++++++++++++++++ > <datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true"> > <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url> > <driver>oracle</driver> > <pool> > <min-pool-size>1</min-pool-size> > <max-pool-size>15</max-pool-size> > </pool> > <security> > <user-name>Test</user-name> > <password>testPassword</password> > </security> > </datasource> > <drivers> > <driver name="oracle" module="com.oracle.jdbc6"> > <driver-class>oracle.jdbc.driver.OracleDriver</driver-class> > </driver> > <driver name="h2" module="com.h2database.h2"> > <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class> > </driver> > </drivers> > ++++++++++++++++ > Then while testing the DataSource the Wildfly throws the following Exception: > +++++++++++++++++++++ > 16:47:10,498 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21] > at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final] > Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base)) > at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101) > at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458) > at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411) > at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490) > at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202) > at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33) > at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474) > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > ++++++++++++++++++++++ -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2995) Using a log4j appender as a custom-handler should invoke the activateOptions if required

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2995?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2995: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1066607|https://bugzilla.redhat.com/show_bug.cgi?id=1066607] from VERIFIED to CLOSED > Using a log4j appender as a custom-handler should invoke the activateOptions if required > ---------------------------------------------------------------------------------------- > > Key: WFLY-2995 > URL: https://issues.jboss.org/browse/WFLY-2995 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Currently the {{OptionHandler.activateOptions}} is only invoked during construction of a log4j appender. This invocation should happen if any property is updated or added. The invocation of this method should also only happen once. Multiple invocation could result in errors or leave the appender in an invalid state. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer + PropertyResolver is broken for vault expressions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBMETA-371: ------------------------------------------------ mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1058959|https://bugzilla.redhat.com/show_bug.cgi?id=1058959] from VERIFIED to CLOSED > DefaultPropertyReplacer + PropertyResolver is broken for vault expressions > -------------------------------------------------------------------------- > > Key: JBMETA-371 > URL: https://issues.jboss.org/browse/JBMETA-371 > Project: JBoss Metadata > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: common > Affects Versions: 7.0.4.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.Final > > > The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname". > This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value". -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on JBEE-146: ---------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from VERIFIED to CLOSED > jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes > -------------------------------------------------------------------------------------- > > Key: JBEE-146 > URL: https://issues.jboss.org/browse/JBEE-146 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final > > > When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs: > {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" > {code} > See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more details. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2493) EL cannot access public methods/fields of non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2493: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from VERIFIED to CLOSED > EL cannot access public methods/fields of non-public classes > ------------------------------------------------------------ > > Key: WFLY-2493 > URL: https://issues.jboss.org/browse/WFLY-2493 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss AS 7.2.0.Final > Reporter: Jonáš Trantina > Fix For: 8.1.0.CR1, 8.1.0.Final > > Attachments: elresolver_stack, reproducer.zip > > > When trying to access public method/field of non-public class that implements public interface via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface. > This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround. > Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking. > I have attached a simple reproducer app as well as a stack trace of the exception. > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1712: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1032627|https://bugzilla.redhat.com/show_bug.cgi?id=1032627] from VERIFIED to CLOSED > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3428) HC should remember the 'run' state of the server instances after crash or shutdown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3428?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3428: ----------------------------------- Labels: EAP todo (was: todo) > HC should remember the 'run' state of the server instances after crash or shutdown > ---------------------------------------------------------------------------------- > > Key: WFLY-3428 > URL: https://issues.jboss.org/browse/WFLY-3428 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Wolf-Dieter Fink > Assignee: Brian Stansberry > Labels: EAP, todo > > The host controller should save which server is currently up and running. This would allow the host controller to bring up all previously running instances on a restart. > The idea is to support the same behavior that other application server (i.e WebLogic) supports. > If a server is started or stopped during the lifetime of the DC/HC it should be in the same state after shutdown the DC/HC or a system crash. > This can be achieved by an optional flag 'set-auto-start-on-start-stop' where the default is false which is the current behaviour. > If set to true, a start of the server instance will set auto-start=true and a stop auto-start=false. > If the server should not be started after a crash for any reason, this can be simple done by setting auto-start=false within the configuration, after starting the server the flag will be set b/c of the 'set-auto-start-on-start-stop' flag. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3428) HC should remember the 'run' state of the server instances after crash or shutdown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3428?page=com.atlassian.jira.plugin.... ] Brian Stansberry moved PRODMGT-847 to WFLY-3428: ------------------------------------------------ Project: WildFly (was: Product Management) Key: WFLY-3428 (was: PRODMGT-847) Workflow: GIT Pull Request workflow (was: JBoss Platforms RFE Workflow v2) Affects Version/s: (was: 6) Component/s: Domain Management (was: Enterprise Application Platform (EAP)) Security: Public > HC should remember the 'run' state of the server instances after crash or shutdown > ---------------------------------------------------------------------------------- > > Key: WFLY-3428 > URL: https://issues.jboss.org/browse/WFLY-3428 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Wolf-Dieter Fink > Assignee: Brian Stansberry > Labels: EAP, todo > > The host controller should save which server is currently up and running. This would allow the host controller to bring up all previously running instances on a restart. > The idea is to support the same behavior that other application server (i.e WebLogic) supports. > If a server is started or stopped during the lifetime of the DC/HC it should be in the same state after shutdown the DC/HC or a system crash. > This can be achieved by an optional flag 'set-auto-start-on-start-stop' where the default is false which is the current behaviour. > If set to true, a start of the server instance will set auto-start=true and a stop auto-start=false. > If the server should not be started after a crash for any reason, this can be simple done by setting auto-start=false within the configuration, after starting the server the flag will be set b/c of the 'set-auto-start-on-start-stop' flag. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3427) Upgrade Narayana to 5.0.2.Final

by Tom Jenkinson (JIRA)

Tom Jenkinson created WFLY-3427: ----------------------------------- Summary: Upgrade Narayana to 5.0.2.Final Key: WFLY-3427 URL: https://issues.jboss.org/browse/WFLY-3427 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 9.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

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