June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-819) LdapExt login module fetches to many attributes in RoleSearch

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-819?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-819: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1086787|https://bugzilla.redhat.com/show_bug.cgi?id=1086787] from POST to MODIFIED > LdapExt login module fetches to many attributes in RoleSearch > ------------------------------------------------------------- > > Key: SECURITY-819 > URL: https://issues.jboss.org/browse/SECURITY-819 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_21.Beta3 > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > > An LDAP server with (lets say) 1000 users in a group. > When authentication, a query is done to retrieve the groups for the user. > Most LDAP servers will limit the attributes send back based on authorization of the user, but can be configured to return *all* information. > The cause is: > / Query for roles matching the role filter > SearchControls constraints = new SearchControls(); > constraints.setSearchScope(searchScope); > constraints.setTimeLimit(searchTimeLimit); > rolesSearch(ctx, constraints, username, userDN, recursion, 0); > this used to also have: > constraints.setReturningAttributes(new String[0]); > at some time this was taken out. > It needs to go back in -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-836) AdvancedLdapLoginModule querying too many attributes.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-836?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-836: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1086787|https://bugzilla.redhat.com/show_bug.cgi?id=1086787] from POST to MODIFIED > AdvancedLdapLoginModule querying too many attributes. > ----------------------------------------------------- > > Key: SECURITY-836 > URL: https://issues.jboss.org/browse/SECURITY-836 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_3_2_Final > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Fix For: Negotiation_2_3_3_Final > > > During the roles search all attributes are being queried instead of the small subset actually required. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3437) Upgrade HAL to 2.2.8.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3437?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3437: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1104216|https://bugzilla.redhat.com/show_bug.cgi?id=1104216] from POST to MODIFIED > Upgrade HAL to 2.2.8.Final > -------------------------- > > Key: WFLY-3437 > URL: https://issues.jboss.org/browse/WFLY-3437 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3441) Upgrade to JBoss Negotiation 2.3.3.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3441?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3441: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1104269|https://bugzilla.redhat.com/show_bug.cgi?id=1104269] from POST to MODIFIED > Upgrade to JBoss Negotiation 2.3.3.Final > ---------------------------------------- > > Key: WFLY-3441 > URL: https://issues.jboss.org/browse/WFLY-3441 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (JBFORUMS-305) No Jboss Cache bridge between 2 clusterd Jboss nodes on JBoss 5.1.0.GA

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/JBFORUMS-305?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on JBFORUMS-305: ------------------------------------------- This is not a forum, it is a legacy project in Jira to track problems with the forums, please use the following location to dicsuss AS5 issues: - https://community.jboss.org/en/jbossas > No Jboss Cache bridge between 2 clusterd Jboss nodes on JBoss 5.1.0.GA > ----------------------------------------------------------------------- > > Key: JBFORUMS-305 > URL: https://issues.jboss.org/browse/JBFORUMS-305 > Project: JBoss Forums > Issue Type: Bug > Components: Documentation > Environment: Jboss 1.5 > Reporter: Manek Kooner > Assignee: Luca Stancapiano > > Hi, > I am using Jboss cache on 2 clustered nodes i.e. 111.111.111.111 and 222.222.222.222 IP's in STAR-CACHE-CLUSTER. > If I change anything in either of the nodes, then jboss cahe should replicate the change to the other node. But, this is happening only 1 time. > In the below log, you can see that the bridge is established between the 2 nodes initially. Then we are getting "No bridge info was associated with this node" and finally "RMI TCP Connection(1)-222.222.222.222: (port 1501) connection closed". > > Any idea why the connection is closing, and the bridge does not work. Nothing has been changed in the code in this regards. Using JBoss 5.1.0.GA. > > 2014-04-18 11:44:13,239 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.STAR-CACHE-CLUSTER] New cluster view for partition STAR-CACHE-CLUSTER (id: 1, delta: 1) : [111.111.111.111:1499, 222.222.222.222:2599] > 2014-04-18 11:44:13,239 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.STAR-CACHE-CLUSTER] I am (111.111.111.111:1499) received membershipChanged event: > 2014-04-18 11:44:13,239 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.STAR-CACHE-CLUSTER] Dead members: 0 ([]) > 2014-04-18 11:44:13,239 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.STAR-CACHE-CLUSTER] New Members : 1 ([222.222.222.222:2599]) > 2014-04-18 11:44:13,239 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.STAR-CACHE-CLUSTER] All Members : 2 ([111.111.111.111:1499, 222.222.222.222:2599]) > 2014-04-18 11:44:13,270 DEBUG [org.jboss.cache.RPCManagerImpl] Block received at 111.111.111.111:53972 > 2014-04-18 11:44:13,270 DEBUG [org.jboss.cache.RPCManagerImpl] Block processed at 111.111.111.111:53972 > 2014-04-18 11:44:13,270 INFO [org.jboss.cache.RPCManagerImpl] Received new cluster view: [111.111.111.111:53972|1] [111.111.111.111:53972, 222.222.222.222:59090] > 2014-04-18 11:44:13,286 DEBUG [org.jboss.cache.statetransfer.DefaultStateTransferManager] locking the / subtree to return the in-memory (transient) state > 2014-04-18 11:44:13,286 DEBUG [org.jboss.cache.statetransfer.DefaultStateTransferManager] Successfully generated state in 0 milliseconds > 2014-04-18 11:44:13,317 DEBUG [org.jboss.cache.RPCManagerImpl] UnBlock received at 111.111.111.111:53972 > 2014-04-18 11:44:13,317 DEBUG [org.jboss.cache.RPCManagerImpl] UnBlock processed at 111.111.111.111:53972 > 2014-04-18 11:44:13,364 FINE [sun.rmi.transport.tcp] RMI TCP Connection(1)-222.222.222.222: accepted socket from [222.222.222.222:57913] > 2014-04-18 11:44:13,364 FINE [sun.rmi.transport.tcp] RMI TCP Connection(1)-222.222.222.222: (port 1501) op = 80 > 2014-04-18 11:44:13,380 FINE [sun.rmi.loader] RMI TCP Connection(1)-222.222.222.222: name = "[Ljava.rmi.server.ObjID;", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@1a45a877 > 2014-04-18 11:44:13,380 FINE [sun.rmi.loader] RMI TCP Connection(1)-222.222.222.222: name = "java.rmi.server.ObjID", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@1a45a877 > 2014-04-18 11:44:13,380 FINE [sun.rmi.loader] RMI TCP Connection(1)-222.222.222.222: name = "java.rmi.server.UID", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@1a45a877 > 2014-04-18 11:44:13,380 FINE [sun.rmi.loader] RMI TCP Connection(1)-222.222.222.222: name = "java.rmi.dgc.Lease", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@1a45a877 > 2014-04-18 11:44:13,380 FINE [sun.rmi.loader] RMI TCP Connection(1)-222.222.222.222: name = "java.rmi.dgc.VMID", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@1a45a877 > 2014-04-18 11:44:13,380 FINE [sun.rmi.loader] RMI TCP Connection(1)-222.222.222.222: name = "[B", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@1a45a877 > 2014-04-18 11:44:13,426 DEBUG [org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge] The list of replicants for the JG bridge has changed, computing and updating local info... > 2014-04-18 11:44:13,426 DEBUG [org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge] ... No bridge info was associated with this node > 2014-04-18 11:44:13,442 FINE [sun.rmi.client.ref] Incoming-8,111.111.111.111:53972: get connection > 2014-04-18 11:44:13,442 FINE [sun.rmi.transport.tcp] Incoming-8,111.111.111.111:53972: create connection > 2014-04-18 11:44:13,442 FINE [sun.rmi.transport.tcp.proxy] Incoming-8,111.111.111.111:53972: host: PTA-TESTVM10, port: 2601 > 2014-04-18 11:44:13,442 FINE [sun.rmi.loader] Incoming-8,111.111.111.111:53972: name = "java.rmi.dgc.Lease", codebase = "", defaultLoader = BaseClassLoader@584ba778{vfsfile:/D:/jboss-5.1.0.GA/server/STAR/conf/jboss-service.xml} > 2014-04-18 11:44:13,442 FINE [sun.rmi.loader] Incoming-8,111.111.111.111:53972: name = "java.rmi.dgc.VMID", codebase = "", defaultLoader = BaseClassLoader@584ba778{vfsfile:/D:/jboss-5.1.0.GA/server/STAR/conf/jboss-service.xml} > 2014-04-18 11:44:13,442 FINE [sun.rmi.loader] Incoming-8,111.111.111.111:53972: name = "[B", codebase = "", defaultLoader = BaseClassLoader@584ba778{vfsfile:/D:/jboss-5.1.0.GA/server/STAR/conf/jboss-service.xml} > 2014-04-18 11:44:13,442 FINE [sun.rmi.loader] Incoming-8,111.111.111.111:53972: name = "java.rmi.server.UID", codebase = "", defaultLoader = BaseClassLoader@584ba778{vfsfile:/D:/jboss-5.1.0.GA/server/STAR/conf/jboss-service.xml} > 2014-04-18 11:44:13,442 FINE [sun.rmi.client.ref] Incoming-8,111.111.111.111:53972: free connection (reuse = true) > 2014-04-18 11:44:13,442 FINE [sun.rmi.transport.tcp] Incoming-8,111.111.111.111:53972: reuse connection > 2014-04-18 11:44:13,442 FINE [sun.rmi.transport.tcp] Incoming-8,111.111.111.111:53972: create reaper > 2014-04-18 11:44:13,442 DEBUG [org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge] The list of replicants for the JG bridge has changed, computing and updating local info... > 2014-04-18 11:44:13,442 DEBUG [org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge] ... No bridge info was associated with this node > 2014-04-18 11:44:28,395 FINE [sun.rmi.transport.tcp] RMI TCP Connection(1)-222.222.222.222: (port 1501) connection closed > 2014-04-18 11:44:28,395 FINE [sun.rmi.transport.tcp] RMI TCP Connection(1)-222.222.222.222: close connection > 2014-04-18 11:44:28,458 FINE [sun.rmi.transport.tcp] RMI Scheduler(0): close connection -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-836) AdvancedLdapLoginModule querying too many attributes.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-836?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-836: -------------------------------------------------- Peter Skopek <pskopek(a)redhat.com> changed the Status of [bug 1086787|https://bugzilla.redhat.com/show_bug.cgi?id=1086787] from NEW to POST > AdvancedLdapLoginModule querying too many attributes. > ----------------------------------------------------- > > Key: SECURITY-836 > URL: https://issues.jboss.org/browse/SECURITY-836 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_3_2_Final > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Fix For: Negotiation_2_3_3_Final > > > During the roles search all attributes are being queried instead of the small subset actually required. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-819) LdapExt login module fetches to many attributes in RoleSearch

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-819?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-819: -------------------------------------------------- Peter Skopek <pskopek(a)redhat.com> changed the Status of [bug 1086787|https://bugzilla.redhat.com/show_bug.cgi?id=1086787] from NEW to POST > LdapExt login module fetches to many attributes in RoleSearch > ------------------------------------------------------------- > > Key: SECURITY-819 > URL: https://issues.jboss.org/browse/SECURITY-819 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_21.Beta3 > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > > An LDAP server with (lets say) 1000 users in a group. > When authentication, a query is done to retrieve the groups for the user. > Most LDAP servers will limit the attributes send back based on authorization of the user, but can be configured to return *all* information. > The cause is: > / Query for roles matching the role filter > SearchControls constraints = new SearchControls(); > constraints.setSearchScope(searchScope); > constraints.setTimeLimit(searchTimeLimit); > rolesSearch(ctx, constraints, username, userDN, recursion, 0); > this used to also have: > constraints.setReturningAttributes(new String[0]); > at some time this was taken out. > It needs to go back in -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-465) Attribute check-for-live-server must set on live server to faillback

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-465?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-465: ---------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> changed the Status of [bug 908261|https://bugzilla.redhat.com/show_bug.cgi?id=908261] from VERIFIED to ASSIGNED > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: WFLY-465 > URL: https://issues.jboss.org/browse/WFLY-465 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 8.2.0.CR1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/inde... > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-465) Attribute check-for-live-server must set on live server to faillback

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-465?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-465: ---------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> changed the Status of [bug 908261|https://bugzilla.redhat.com/show_bug.cgi?id=908261] from ON_QA to VERIFIED > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: WFLY-465 > URL: https://issues.jboss.org/browse/WFLY-465 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 8.2.0.CR1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/inde... > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-3386: ------------------------------- Comment: was deleted (was: Ok, what's the lifespan of the Activiti BusinessProcess? Does it stop before the servlet request completes?) > Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI > --------------------------------------------------------------------------------------- > > Key: WFLY-3386 > URL: https://issues.jboss.org/browse/WFLY-3386 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final > Environment: CentOS, Mac (Mountain Lion). > Reporter: Andries Ehlers > Assignee: Martin Kouba > > Background: > The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI. > Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise. > Error: > We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below). > ----------------------------- > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na] > 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na] -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2014