January 2016 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3945) Set property that causes 400 error message to be returned by apache CXF.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3945?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWS-3945: ----------------------------------------------- pmackay(a)redhat.com changed the Status of [bug 1182919|https://bugzilla.redhat.com/show_bug.cgi?id=1182919] from ON_QA to VERIFIED > Set property that causes 400 error message to be returned by apache CXF. > ------------------------------------------------------------------------ > > Key: JBWS-3945 > URL: https://issues.jboss.org/browse/JBWS-3945 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.1.0.Beta1 > Reporter: R Searls > Assignee: Alessio Soldano > Priority: Minor > Fix For: jbossws-cxf-5.1.1.Final > > > Change ./modules/client/src/main/java/org/jboss/wsf/stack/cxf/saaj/SOAPConnectionImpl.java -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3964) Incorrect behaviour with @WebParam(header = true, mode = IN)

by Xavier Dury (JIRA)

[ https://issues.jboss.org/browse/JBWS-3964?page=com.atlassian.jira.plugin.... ] Xavier Dury commented on JBWS-3964: ----------------------------------- I want to put some extra debugging/testing information in the headers which are not part of the schema so validation is not a problem for me. > Incorrect behaviour with @WebParam(header = true, mode = IN) > ------------------------------------------------------------ > > Key: JBWS-3964 > URL: https://issues.jboss.org/browse/JBWS-3964 > Project: JBoss Web Services > Issue Type: Bug > Environment: Wildfly 9.0.2 > Reporter: Xavier Dury > Assignee: Jim Ma > Fix For: jbossws-cxf-5.2.0.Final > > > Given the following simple WebService with incoming and outgoing header @WebParams: > {code} > @Stateless > @WebService(name = "MyEchoService", targetNamespace = "urn:echo") > public class MyEchoService { > > @WebResult(name = "result") > public String echo( > @WebParam(name = "message") String message, > @WebParam(name = "paramIn", mode = Mode.IN, header = true) Holder<String> paramIn, > @WebParam(name = "paramOut", mode = Mode.OUT, header = true) Holder<String> paramOut) { > paramOut.value = "got paramIn " + paramIn.value; > return "echo " + message; > } > } > {code} > The generated WSDL contains the following operation where the incoming @WebParam (mode = IN) is present in both input and ouput: > {code} > <wsdl:operation name="echo"> > <soap:operation soapAction="" style="document"/> > <wsdl:input name="echo"> > <soap:header message="tns:echo" part="paramIn" use="literal"></soap:header> > <soap:body parts="parameters" use="literal"/> > </wsdl:input> > <wsdl:output name="echoResponse"> > <soap:header message="tns:echoResponse" part="paramIn" use="literal"></soap:header> > <soap:header message="tns:echoResponse" part="paramOut" use="literal"></soap:header> > <soap:body parts="result" use="literal"/> > </wsdl:output> > </wsdl:operation> > {code} > We can see in the following exchange that the incoming @WebParam will be copied verbatim in the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Header> > <urn:paramIn>fred</urn:paramIn> > </soapenv:Header> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramIn xmlns="urn:echo">fred</paramIn> > <paramOut xmlns="urn:echo">got paramIn fred</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > </soap:Body> > </soap:Envelope> > {code} > When the incoming header @WebParam is not set, an empty element will be added to the body of the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramOut xmlns="urn:echo">got paramIn null</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > <paramIn xsi:nil="true" xmlns="urn:echo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> > </soap:Body> > </soap:Envelope> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3964) Incorrect behaviour with @WebParam(header = true, mode = IN)

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3964?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-3964: ------------------------------ [~kalgon] This is a bug in cxf. I'll try to fix this later in apache cxf: https://issues.apache.org/jira/browse/CXF-6752. BTW,Put the element in soap header is not easy to validate with schema. Why do you need to set header to true? Does move this element to soap body work for you? > Incorrect behaviour with @WebParam(header = true, mode = IN) > ------------------------------------------------------------ > > Key: JBWS-3964 > URL: https://issues.jboss.org/browse/JBWS-3964 > Project: JBoss Web Services > Issue Type: Bug > Environment: Wildfly 9.0.2 > Reporter: Xavier Dury > Assignee: Jim Ma > Fix For: jbossws-cxf-5.2.0.Final > > > Given the following simple WebService with incoming and outgoing header @WebParams: > {code} > @Stateless > @WebService(name = "MyEchoService", targetNamespace = "urn:echo") > public class MyEchoService { > > @WebResult(name = "result") > public String echo( > @WebParam(name = "message") String message, > @WebParam(name = "paramIn", mode = Mode.IN, header = true) Holder<String> paramIn, > @WebParam(name = "paramOut", mode = Mode.OUT, header = true) Holder<String> paramOut) { > paramOut.value = "got paramIn " + paramIn.value; > return "echo " + message; > } > } > {code} > The generated WSDL contains the following operation where the incoming @WebParam (mode = IN) is present in both input and ouput: > {code} > <wsdl:operation name="echo"> > <soap:operation soapAction="" style="document"/> > <wsdl:input name="echo"> > <soap:header message="tns:echo" part="paramIn" use="literal"></soap:header> > <soap:body parts="parameters" use="literal"/> > </wsdl:input> > <wsdl:output name="echoResponse"> > <soap:header message="tns:echoResponse" part="paramIn" use="literal"></soap:header> > <soap:header message="tns:echoResponse" part="paramOut" use="literal"></soap:header> > <soap:body parts="result" use="literal"/> > </wsdl:output> > </wsdl:operation> > {code} > We can see in the following exchange that the incoming @WebParam will be copied verbatim in the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Header> > <urn:paramIn>fred</urn:paramIn> > </soapenv:Header> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramIn xmlns="urn:echo">fred</paramIn> > <paramOut xmlns="urn:echo">got paramIn fred</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > </soap:Body> > </soap:Envelope> > {code} > When the incoming header @WebParam is not set, an empty element will be added to the body of the response: > {code} > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:echo"> > <soapenv:Body> > <urn:echo> > <urn:message>hello world!</urn:message> > </urn:echo> > </soapenv:Body> > </soapenv:Envelope> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <paramOut xmlns="urn:echo">got paramIn null</paramOut> > </soap:Header> > <soap:Body> > <echoResponse xmlns="urn:echo"> > <result>echo hello world!</result> > </echoResponse> > <paramIn xsi:nil="true" xmlns="urn:echo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> > </soap:Body> > </soap:Envelope> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3974) Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly

by Jason Shepherd (JIRA)

[ https://issues.jboss.org/browse/JBWS-3974?page=com.atlassian.jira.plugin.... ] Jason Shepherd commented on JBWS-3974: -------------------------------------- [~jim.ma] If a user's code is performing a sensitive operation which they want to define a custom grant for they should use the securityManager.checkPermission(). Using a Security Manager allows for centralization of the access control policies. For more information, read chapter 9 of the Oracle Secure Coding guide: [http://www.oracle.com/technetwork/java/seccodeguide-139067.html] > Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly > ---------------------------------------------------------------------------------------- > > Key: JBWS-3974 > URL: https://issues.jboss.org/browse/JBWS-3974 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-integration > Environment: EAP 7.0.0.Beta1, jbossws-spi 3.1.1 (Couldn't find in affected version list) > Reporter: Jason Shepherd > Assignee: Jim Ma > Priority: Minor > Fix For: jbossws-cxf-5.2.0.Final > > > Calls to AccessControl.checkPermission() should be done by the Security Manager so that policies can be centrally managed. See this guide as a reference: > bq. Note that the method AccessController.checkPermission is normally invoked indirectly through invocations of specific SecurityManager methods that begin with the word check such as checkConnect or through the method SecurityManager.checkPermission. Normally, these checks only occur if a SecurityManager has been installed; code checked by the AccessController.checkPermission method first checks if the method System.getSecurityManager returns null. > [https://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivile...] > Also refer to fixed issue WFCORE-1266, as it is similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3974) Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3974?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3974: ---------------------------------- Assignee: Jim Ma > Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly > ---------------------------------------------------------------------------------------- > > Key: JBWS-3974 > URL: https://issues.jboss.org/browse/JBWS-3974 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-integration > Environment: EAP 7.0.0.Beta1, jbossws-spi 3.1.1 (Couldn't find in affected version list) > Reporter: Jason Shepherd > Assignee: Jim Ma > Priority: Minor > Fix For: jbossws-cxf-5.2.0.Final > > > Calls to AccessControl.checkPermission() should be done by the Security Manager so that policies can be centrally managed. See this guide as a reference: > bq. Note that the method AccessController.checkPermission is normally invoked indirectly through invocations of specific SecurityManager methods that begin with the word check such as checkConnect or through the method SecurityManager.checkPermission. Normally, these checks only occur if a SecurityManager has been installed; code checked by the AccessController.checkPermission method first checks if the method System.getSecurityManager returns null. > [https://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivile...] > Also refer to fixed issue WFCORE-1266, as it is similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3974) Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3974?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3974: ---------------------------------- Fix Version/s: jbossws-cxf-5.2.0.Final > Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly > ---------------------------------------------------------------------------------------- > > Key: JBWS-3974 > URL: https://issues.jboss.org/browse/JBWS-3974 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-integration > Environment: EAP 7.0.0.Beta1, jbossws-spi 3.1.1 (Couldn't find in affected version list) > Reporter: Jason Shepherd > Priority: Minor > Fix For: jbossws-cxf-5.2.0.Final > > > Calls to AccessControl.checkPermission() should be done by the Security Manager so that policies can be centrally managed. See this guide as a reference: > bq. Note that the method AccessController.checkPermission is normally invoked indirectly through invocations of specific SecurityManager methods that begin with the word check such as checkConnect or through the method SecurityManager.checkPermission. Normally, these checks only occur if a SecurityManager has been installed; code checked by the AccessController.checkPermission method first checks if the method System.getSecurityManager returns null. > [https://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivile...] > Also refer to fixed issue WFCORE-1266, as it is similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3971) cxf-rt-*-jandex.jar archives generation not needed anymore

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/JBWS-3971?page=com.atlassian.jira.plugin.... ] Rostislav Svoboda commented on JBWS-3971: ----------------------------------------- I did some performance checks when jandex is not generated and I wasn't able to notice any performance degradation. This is good news ;) > cxf-rt-*-jandex.jar archives generation not needed anymore > ---------------------------------------------------------- > > Key: JBWS-3971 > URL: https://issues.jboss.org/browse/JBWS-3971 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.1.3.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3974) Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3974?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-3974: ------------------------------ Another change : https://github.com/jbossws/jbossws-common/commit/638224b5adff1fab08095a89... > Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly > ---------------------------------------------------------------------------------------- > > Key: JBWS-3974 > URL: https://issues.jboss.org/browse/JBWS-3974 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-integration > Environment: EAP 7.0.0.Beta1, jbossws-spi 3.1.1 (Couldn't find in affected version list) > Reporter: Jason Shepherd > Priority: Minor > > Calls to AccessControl.checkPermission() should be done by the Security Manager so that policies can be centrally managed. See this guide as a reference: > bq. Note that the method AccessController.checkPermission is normally invoked indirectly through invocations of specific SecurityManager methods that begin with the word check such as checkConnect or through the method SecurityManager.checkPermission. Normally, these checks only occur if a SecurityManager has been installed; code checked by the AccessController.checkPermission method first checks if the method System.getSecurityManager returns null. > [https://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivile...] > Also refer to fixed issue WFCORE-1266, as it is similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3974) Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3974?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-3974: ------------------------------ [~jshepher] Should user's code also use securityManager.checkPermission() instead of AcessController.checkPermission() ? > Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly > ---------------------------------------------------------------------------------------- > > Key: JBWS-3974 > URL: https://issues.jboss.org/browse/JBWS-3974 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-integration > Environment: EAP 7.0.0.Beta1, jbossws-spi 3.1.1 (Couldn't find in affected version list) > Reporter: Jason Shepherd > Priority: Minor > > Calls to AccessControl.checkPermission() should be done by the Security Manager so that policies can be centrally managed. See this guide as a reference: > bq. Note that the method AccessController.checkPermission is normally invoked indirectly through invocations of specific SecurityManager methods that begin with the word check such as checkConnect or through the method SecurityManager.checkPermission. Normally, these checks only occur if a SecurityManager has been installed; code checked by the AccessController.checkPermission method first checks if the method System.getSecurityManager returns null. > [https://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivile...] > Also refer to fixed issue WFCORE-1266, as it is similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3974) Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly

by Jason Shepherd (JIRA)

[ https://issues.jboss.org/browse/JBWS-3974?page=com.atlassian.jira.plugin.... ] Jason Shepherd updated JBWS-3974: --------------------------------- Git Pull Request: https://github.com/jbossws/jbossws-spi/pull/1 > Incorreclty bypass the SecurityManager and call AccessControl.checkPermission() directly > ---------------------------------------------------------------------------------------- > > Key: JBWS-3974 > URL: https://issues.jboss.org/browse/JBWS-3974 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-integration > Environment: EAP 7.0.0.Beta1, jbossws-spi 3.1.1 (Couldn't find in affected version list) > Reporter: Jason Shepherd > Priority: Minor > > Calls to AccessControl.checkPermission() should be done by the Security Manager so that policies can be centrally managed. See this guide as a reference: > bq. Note that the method AccessController.checkPermission is normally invoked indirectly through invocations of specific SecurityManager methods that begin with the word check such as checkConnect or through the method SecurityManager.checkPermission. Normally, these checks only occur if a SecurityManager has been installed; code checked by the AccessController.checkPermission method first checks if the method System.getSecurityManager returns null. > [https://docs.oracle.com/javase/8/docs/technotes/guides/security/doprivile...] > Also refer to fixed issue WFCORE-1266, as it is similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 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 January 2016