April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-815: -------------------------------------- Fix Version/s: Negotiation_2_2_8 > NegotiationAuthenticator loses post data > ---------------------------------------- > > Key: SECURITY-815 > URL: https://issues.jboss.org/browse/SECURITY-815 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2 > > > The NegotiationAuthenticator loses post data. > A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding. > If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL. > If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-793) Add support to fall back to BASIC authentication.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-793?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-793: -------------------------------------- Fix Version/s: Negotiation_2_2_8 > Add support to fall back to BASIC authentication. > ------------------------------------------------- > > Key: SECURITY-793 > URL: https://issues.jboss.org/browse/SECURITY-793 > Project: PicketBox > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_1_5, Negotiation_2_2_8 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-793) Add support to fall back to BASIC authentication.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-793?page=com.atlassian.jira.plug... ] Darran Lofthouse resolved SECURITY-793. --------------------------------------- Resolution: Done > Add support to fall back to BASIC authentication. > ------------------------------------------------- > > Key: SECURITY-793 > URL: https://issues.jboss.org/browse/SECURITY-793 > Project: PicketBox > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_8, Negotiation_2_1_5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-793) Add support to fall back to BASIC authentication.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-793?page=com.atlassian.jira.plug... ] Darran Lofthouse reopened SECURITY-793: --------------------------------------- > Add support to fall back to BASIC authentication. > ------------------------------------------------- > > Key: SECURITY-793 > URL: https://issues.jboss.org/browse/SECURITY-793 > Project: PicketBox > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_1_5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-456) ResourceConfigurationImpl class not found when using drools-karaf-feature

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-456?page=com.atlassian.jira.plugin... ] Edson Tirelli reassigned DROOLS-456: ------------------------------------ Assignee: Mario Fusco (was: Mark Proctor) > ResourceConfigurationImpl class not found when using drools-karaf-feature > ------------------------------------------------------------------------- > > Key: DROOLS-456 > URL: https://issues.jboss.org/browse/DROOLS-456 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta1 > Reporter: Gary Brown > Assignee: Mario Fusco > Attachments: fuse-drools-issue.log > > > While porting RTGov to Karaf, I have been using Drools 2.0.0.CR5 successfully. > However when I updated the version to 2.0.1.Final, and subsequently to 2.1.0.Beta1, I now get a class not found issue: > {noformat} > 11:26:49,440 | ERROR | l Console Thread | ResourceTypeImpl | 290 - org.kie.internalapi - 6.1.0.20140307-1723 | Error loading resource configuration from properties > java.lang.ClassNotFoundException: org.drools.core.builder.conf.impl.ResourceConfigurationImpl not found by org.kie.internalapi [290] > at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.0.3.redhat-610355.jar:] > at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.0.3.redhat-610355.jar:] > at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356)[:1.7.0_07] > at java.lang.Class.forName0(Native Method)[:1.7.0_07] > at java.lang.Class.forName(Class.java:186)[:1.7.0_07] > at org.kie.internal.io.ResourceTypeImpl.fromProperties(ResourceTypeImpl.java:41)[290:org.kie.internalapi:6.1.0.20140307-1723] > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-821) SPNEGOSocket does not throw Exception in case it fails to establish GSSContext

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-821?page=com.atlassian.jira.plug... ] Darran Lofthouse resolved SECURITY-821. --------------------------------------- Fix Version/s: (was: Negotiation_2_2_8) (was: Negotiation_2_3_1_Final) Resolution: Done > SPNEGOSocket does not throw Exception in case it fails to establish GSSContext > ------------------------------------------------------------------------------ > > Key: SECURITY-821 > URL: https://issues.jboss.org/browse/SECURITY-821 > Project: PicketBox > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_1_5, Negotiation_2_2_7, Negotiation_2_3_0_Final > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: Negotiation_2_1_6 > > > Point of failure: https://github.com/wildfly/jboss-negotiation/blob/master/jboss-negotiatio... > Socket in mentioned versions log error and allow connection to be up. This is a cause of hangup in case of proxy lookup( atleast in EAP5 - JBPAPP-10748 ) > Code should terminate connection and throw exception upstream, in case login/logout(?) failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-460) Eval does not behave as intended

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-460?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-460: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1089285|https://bugzilla.redhat.com/show_bug.cgi?id=1089285] from ASSIGNED to MODIFIED > Eval does not behave as intended > -------------------------------- > > Key: DROOLS-460 > URL: https://issues.jboss.org/browse/DROOLS-460 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Final > Reporter: Fabian Meyer > Assignee: Mario Fusco > Fix For: 6.1.0.Beta3 > > > Under certain conditions, eval does not behave as intended, when nested in a sub-network. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1831) Differentiate exception from remote methods and JGroup Framework

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1831?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1831: --------------------------- Fix Version/s: 3.5 Priority: Minor (was: Major) > Differentiate exception from remote methods and JGroup Framework > ------------------------------------------------------------------ > > Key: JGRP-1831 > URL: https://issues.jboss.org/browse/JGRP-1831 > Project: JGroups > Issue Type: Feature Request > Reporter: Bastien Aracil > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > Looking at the API and code, it seems there is no clean way to differentiate the exceptions thrown by the called method/service and those thrown by JGroups Framework (timeout, supected, unreachable, serialization error and such). > Exception thrown by the called method/service should be wrap in an specific exception (like InvocationTargetException) to ease the exception handling by the developper. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1831) Differentiate exception from remote methods and JGroups Framework

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1831?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1831: --------------------------- Summary: Differentiate exception from remote methods and JGroups Framework (was: Differentiate exception from remote methods and JGroup Framework ) > Differentiate exception from remote methods and JGroups Framework > ------------------------------------------------------------------- > > Key: JGRP-1831 > URL: https://issues.jboss.org/browse/JGRP-1831 > Project: JGroups > Issue Type: Feature Request > Reporter: Bastien Aracil > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > Looking at the API and code, it seems there is no clean way to differentiate the exceptions thrown by the called method/service and those thrown by JGroups Framework (timeout, supected, unreachable, serialization error and such). > Exception thrown by the called method/service should be wrap in an specific exception (like InvocationTargetException) to ease the exception handling by the developper. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently

by Remy Maucherat (JIRA)

[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ] Remy Maucherat edited comment on JBWEB-297 at 4/22/14 10:08 AM: ---------------------------------------------------------------- Ok, thanks for the work on this. Can you confirm the simple sync I sent you in NioEndpoint.ChannelProcessor.run() fixes it for your test case ? was (Author: rmaucher): Ok, thanks for the work on this. Can you confirm the simple sync I sent you in NioEndpoint.ChannelProcessor.run() I sent you fixes it for your test case ? > NIO can improperly lead to request/response objects being used concurrently > --------------------------------------------------------------------------- > > Key: JBWEB-297 > URL: https://issues.jboss.org/browse/JBWEB-297 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > > Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event(): > {code:title=Http11NioProtocol.java|borderStyle=solid} > public SocketState event(NioChannel channel, SocketStatus status) { > Http11NioProcessor processor = connections.get(channel.getId()); > SocketState state = SocketState.CLOSED; > if (processor != null) { > processor.startProcessing(); > // Call the appropriate event > try { > state = processor.event(status); > } catch (java.net.SocketException e) { > // SocketExceptions are normal > CoyoteLogger.HTTP_NIO_LOGGER.socketException(e); > } catch (java.io.IOException e) { > // IOExceptions are normal > CoyoteLogger.HTTP_NIO_LOGGER.socketException(e); > } > // Future developers: if you discover any other > // rare-but-nonfatal exceptions, catch them here, and log as > // above. > catch (Throwable e) { > // any other exception or error is odd. Here we log it > // with "ERROR" level, so it will show up even on > // less-than-verbose logs. > CoyoteLogger.HTTP_NIO_LOGGER.socketError(e); > } finally { > if (state != SocketState.LONG) { > connections.remove(channel.getId()); > recycledProcessors.offer(processor); > {code} > If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors. > It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

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