January 2015 - jboss-jira - Jboss List Archives

[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 commented on SECURITY-868: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1173492|https://bugzilla.redhat.com/show_bug.cgi?id=1173492] from MODIFIED to ON_QA > 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)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1878: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1167666|https://bugzilla.redhat.com/show_bug.cgi?id=1167666] from MODIFIED to ON_QA > Multicast discovery does not work on JDK8 > ----------------------------------------- > > Key: JGRP-1878 > URL: https://issues.jboss.org/browse/JGRP-1878 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12, 3.5 > Environment: OpenJDK8, OracleJDK8u40 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 3.2.14, 3.6 > > Attachments: mcast.java > > > Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8. > Steps to reproduce with draw, switch to JDK8: > {noformat} > export IP_ADDR=127.0.0.1 > ./draw.sh > export IP_ADDR=192.168.1.10 > ./draw.sh > {noformat} > Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug.. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3942) Race condition with clean shutdown and mod_cluster session draining

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3942?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3942: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1161079|https://bugzilla.redhat.com/show_bug.cgi?id=1161079] from MODIFIED to ON_QA > Race condition with clean shutdown and mod_cluster session draining > ------------------------------------------------------------------- > > Key: WFLY-3942 > URL: https://issues.jboss.org/browse/WFLY-3942 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > Probably same issue exists in WF as well, I will revalidate the logic for race conditions. > https://issues.jboss.org/browse/MODCLUSTER-399 > https://bugzilla.redhat.com/show_bug.cgi?id=1083563 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3266: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1127593|https://bugzilla.redhat.com/show_bug.cgi?id=1127593] from MODIFIED to ON_QA > Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-3266 > URL: https://issues.jboss.org/browse/WFLY-3266 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > Priority: Critical > > In case of large parameter input for EJB invocations the ejb-client throw the Exception below. > The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found. > java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed > at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200) > at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256) > at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) > at com.sun.proxy.$Proxy6.uploadData(Unknown Source) > at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3580) Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3580?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3580: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1123505|https://bugzilla.redhat.com/show_bug.cgi?id=1123505] from MODIFIED to ON_QA > Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3580 > URL: https://issues.jboss.org/browse/WFLY-3580 > Project: WildFly > Issue Type: Bug > Components: Domain Management, EJB > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-242: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1163173|https://bugzilla.redhat.com/show_bug.cgi?id=1163173] from MODIFIED to ON_QA > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha14 > > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[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: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1170764|https://bugzilla.redhat.com/show_bug.cgi?id=1170764] from MODIFIED to ON_QA > 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)

11 years, 6 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: ------------------------------------------------ Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1172681|https://bugzilla.redhat.com/show_bug.cgi?id=1172681] from MODIFIED to ON_QA > 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)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3966) Allow soapFaults to be returned for HTTP_BAD_REQUEST are per SOAP 1.2 spec

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3966?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3966: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1151530|https://bugzilla.redhat.com/show_bug.cgi?id=1151530] from ASSIGNED to ON_QA > Allow soapFaults to be returned for HTTP_BAD_REQUEST are per SOAP 1.2 spec > -------------------------------------------------------------------------- > > Key: WFLY-3966 > URL: https://issues.jboss.org/browse/WFLY-3966 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > Assignee: Bartosz Baranowski > Attachments: SAAJ-74.patch > > > SOAP 1.2 spec says that HTTP 400 should return a soapFault error. At the moment the code only returns SoapFault for HTTP 500 which is wrong. > The issue is recorded in the SAAJ JIRA: https://java.net/jira/browse/SAAJ-74 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-764) Enhance the security realm plug-in mechanism for client-cert / external verification.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-764?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-764: ---------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1123505|https://bugzilla.redhat.com/show_bug.cgi?id=1123505] from MODIFIED to ON_QA > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFLY-764 > URL: https://issues.jboss.org/browse/WFLY-764 > Project: WildFly > Issue Type: Task > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Labels: Realm_Management > Fix For: Awaiting Volunteers > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

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 January 2015