October 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3843) Username Token Digest Authentication failure with EJB3 endpoints

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3843?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3843: ---------------------------------- Description: EJB3 Web Service using username token for digest authentication fails when you load test it with parallel invocations. See attached reproducer. (was: EJB3 Web Service using username token for authentication fails when you load test it with parallel invocations. See attached reproducer.) > Username Token Digest Authentication failure with EJB3 endpoints > ---------------------------------------------------------------- > > Key: JBWS-3843 > URL: https://issues.jboss.org/browse/JBWS-3843 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration, ws-security > Affects Versions: jbossws-cxf-4.3.1 > Environment: JBoss EAP 6.3.1 > Reporter: Mustafa Musaji > Assignee: Jim Ma > Priority: Critical > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0 > > Attachments: ClientSample.java, javaee-ws-with-security_1413372207000.zip > > > EJB3 Web Service using username token for digest authentication fails when you load test it with parallel invocations. See attached reproducer. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3843) Username Token Digest Authentication failure with EJB3 endpoints

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3843?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3843: ---------------------------------- Summary: Username Token Digest Authentication failure with EJB3 endpoints (was: EJB3 Web Service returns Invalid User on parallel invocations) > Username Token Digest Authentication failure with EJB3 endpoints > ---------------------------------------------------------------- > > Key: JBWS-3843 > URL: https://issues.jboss.org/browse/JBWS-3843 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration, ws-security > Affects Versions: jbossws-cxf-4.3.1 > Environment: JBoss EAP 6.3.1 > Reporter: Mustafa Musaji > Assignee: Jim Ma > Priority: Critical > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0 > > Attachments: ClientSample.java, javaee-ws-with-security_1413372207000.zip > > > EJB3 Web Service using username token for authentication fails when you load test it with parallel invocations. See attached reproducer. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3853) JBossWS 4.3.2.Final errata

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3853?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3853: --------------------------------------- WildFly 8.0.0.Final & WildFly 8.1.0.Final * [JBWS-2561] XOP request not properly inlined * [JBWS-2480] Soap attachments are dropped on server response * [JBWS-3620] Authentication failures w/ Undertow * FIXME: [CXF-1519] Explicitely set the namespace of a WebFault * FIXME: [CXF-2531] Wrong "transport" attribute in soap12:binding * FIXME: [CXF-4600] Exception inheritance not working over SOAP protocol * FIXME: [JBWS-3330] RMI class loader disabled / CNFE with remote classloader * [JBWS-3702] FIXME: Add support for https protocol > JBossWS 4.3.2.Final errata > -------------------------- > > Key: JBWS-3853 > URL: https://issues.jboss.org/browse/JBWS-3853 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3853) JBossWS 4.3.2.Final errata

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3853?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3853: --------------------------------------- JBoss AS 7.2.0.Final * [JBWS-2561] XOP request not properly inlined * [JBWS-2480] Soap attachments are dropped on server response * [PLFED-390] PicketLink STS chokes on WS-Policy 1.5 tags * [AS7-537] Fixed on AS 8 or greater * [JBWS-3560] fastinfoset module is required in as720 * [WFLY-308] Provide facility for running ejb3 ws endpoints authorization independently * FIXME: [CXF-1519] Explicitely set the namespace of a WebFault * FIXME: [CXF-2531] Wrong "transport" attribute in soap12:binding * FIXME: [CXF-4600] Exception inheritance not working over SOAP protocol * FIXME: [JBWS-3330] RMI class loader disabled / CNFE with remote classloader * [JBWS-3079] FIXME: Add support for https protocol * [JBWS-3702] FIXME: Add support for https protocol * [WELD-1328] @WebServiceRef injection not working w/ Weld 1.x > JBossWS 4.3.2.Final errata > -------------------------- > > Key: JBWS-3853 > URL: https://issues.jboss.org/browse/JBWS-3853 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3853) JBossWS 4.3.2.Final errata

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3853?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3853: ---------------------------------- Fix Version/s: jbossws-cxf-4.3.2 (was: jbossws-cxf-4.3.1) > JBossWS 4.3.2.Final errata > -------------------------- > > Key: JBWS-3853 > URL: https://issues.jboss.org/browse/JBWS-3853 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3853) JBossWS 4.3.2.Final errata

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3853: ------------------------------------- Summary: JBossWS 4.3.2.Final errata Key: JBWS-3853 URL: https://issues.jboss.org/browse/JBWS-3853 Project: JBoss Web Services Issue Type: Task Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.3.1 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3847?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3847: ---------------------------------- Fix Version/s: jbossws-cxf-4.3.2 > Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor > ---------------------------------------------------------------- > > Key: JBWS-3847 > URL: https://issues.jboss.org/browse/JBWS-3847 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.3 > Reporter: Tadayoshi Sato > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0 > > > {{HandlerChainSortInterceptor.handleMessage(Message)}} sorts and sets JAX-WS handlers every time it handles a SOAP message: > {code:java} > public void handleMessage(Message message) throws Fault > { > if (binding != null) { > @SuppressWarnings("rawtypes") > List<Handler> list = binding.getHandlerChain(); > if (list != null && !list.isEmpty()) { > Collections.sort(list, comparator); > binding.setHandlerChain(list); > } > } > } > {code} > However, inside the {{org.apache.cxf.jaxws.binding.AbstractBindingImpl}} and {{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} implementations the handler chain is not reset every time but piled up with interceptors, which leads to subtle but indefinite memory leak in JBoss WS CXF client. > Furthermore, {{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} holds the interceptors as a kind of {{java.util.concurrent.CopyOnWriteArrayList}}. So modifying the growing list of interceptors per each message should cause a growing performance drawback, which is also not a good implementation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-2680) Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm"

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-2680?page=com.atlassian.jira.plugin.... ] Jim Ma updated JBWS-2680: ------------------------- Issue Type: Task (was: Feature Request) Affects Version/s: jbossws-cxf-5.0.0.Beta1 > Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm" > ------------------------------------------------------------------------- > > Key: JBWS-2680 > URL: https://issues.jboss.org/browse/JBWS-2680 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Affects Versions: jbossws-native-3.0.5, jbossws-cxf-5.0.0.Beta1 > Environment: JBossAS 4.2.3 with JBossWS 3.0.5 > Reporter: Gerald Turner > Assignee: Jim Ma > Priority: Optional > Fix For: jbossws-cxf-5.0 > > > An EJB3 endpoint defined with annotation @WebContext(authMethod="BASIC") results in JBossWS generating web.xml metadata equivalent to: > <login-config> > <auth-method>BASIC</auth-method> > <realm-name>EJBServiceEndpointServlet Realm</realm-name> > </login-config> > On one hand this is perfectly acceptable as the realm-name is just a vanity configuration parameter. However there are scenarios where it would be desirable to allow the application to override the default value: we migrated from another web services stack to JBossWS (was JAXWS-RI), some clients of our web services had explicitly configured their HTTP authentication on their end to match on realm name (one instance was Perl SOAP::Lite), quite the same way a web browser stores HTTP authentication along with the realm name such if the realm name changes, the authentication is invalidated - but since these are machines talking to each other rather than a web browser, it becomes a nightmare to debug why a client began receiving 401 errors after our upgrade. > It would be nice if the org.jboss.wsf.spi.annotation.WebContext annotation had a realmName parameter. > I attempted to work on a patch, however I'm confused by how many copies of WebAppGeneratorDeploymentAspect.java there seem to be under the jbossws/container and jbossws/framework subversion trees. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-2680) Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm"

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-2680?page=com.atlassian.jira.plugin.... ] Jim Ma reopened JBWS-2680: -------------------------- > Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm" > ------------------------------------------------------------------------- > > Key: JBWS-2680 > URL: https://issues.jboss.org/browse/JBWS-2680 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Affects Versions: jbossws-native-3.0.5, jbossws-cxf-5.0.0.Beta1 > Environment: JBossAS 4.2.3 with JBossWS 3.0.5 > Reporter: Gerald Turner > Assignee: Jim Ma > Priority: Optional > Fix For: jbossws-cxf-5.0 > > > An EJB3 endpoint defined with annotation @WebContext(authMethod="BASIC") results in JBossWS generating web.xml metadata equivalent to: > <login-config> > <auth-method>BASIC</auth-method> > <realm-name>EJBServiceEndpointServlet Realm</realm-name> > </login-config> > On one hand this is perfectly acceptable as the realm-name is just a vanity configuration parameter. However there are scenarios where it would be desirable to allow the application to override the default value: we migrated from another web services stack to JBossWS (was JAXWS-RI), some clients of our web services had explicitly configured their HTTP authentication on their end to match on realm name (one instance was Perl SOAP::Lite), quite the same way a web browser stores HTTP authentication along with the realm name such if the realm name changes, the authentication is invalidated - but since these are machines talking to each other rather than a web browser, it becomes a nightmare to debug why a client began receiving 401 errors after our upgrade. > It would be nice if the org.jboss.wsf.spi.annotation.WebContext annotation had a realmName parameter. > I attempted to work on a patch, however I'm confused by how many copies of WebAppGeneratorDeploymentAspect.java there seem to be under the jbossws/container and jbossws/framework subversion trees. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWS-2680) Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm"

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-2680?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-2680: ------------------------------ https://github.com/wildfly/wildfly/pull/6887 is sent. I'll close after it is merged. > Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm" > ------------------------------------------------------------------------- > > Key: JBWS-2680 > URL: https://issues.jboss.org/browse/JBWS-2680 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Affects Versions: jbossws-native-3.0.5, jbossws-cxf-5.0.0.Beta1 > Environment: JBossAS 4.2.3 with JBossWS 3.0.5 > Reporter: Gerald Turner > Assignee: Jim Ma > Priority: Optional > Fix For: jbossws-cxf-5.0 > > > An EJB3 endpoint defined with annotation @WebContext(authMethod="BASIC") results in JBossWS generating web.xml metadata equivalent to: > <login-config> > <auth-method>BASIC</auth-method> > <realm-name>EJBServiceEndpointServlet Realm</realm-name> > </login-config> > On one hand this is perfectly acceptable as the realm-name is just a vanity configuration parameter. However there are scenarios where it would be desirable to allow the application to override the default value: we migrated from another web services stack to JBossWS (was JAXWS-RI), some clients of our web services had explicitly configured their HTTP authentication on their end to match on realm name (one instance was Perl SOAP::Lite), quite the same way a web browser stores HTTP authentication along with the realm name such if the realm name changes, the authentication is invalidated - but since these are machines talking to each other rather than a web browser, it becomes a nightmare to debug why a client began receiving 401 errors after our upgrade. > It would be nice if the org.jboss.wsf.spi.annotation.WebContext annotation had a realmName parameter. > I attempted to work on a patch, however I'm confused by how many copies of WebAppGeneratorDeploymentAspect.java there seem to be under the jbossws/container and jbossws/framework subversion trees. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues October 2014