[jira] [Commented] (CXF-6777) javax.net.ssl.SSLKeyException: Hostname verification failed on WLS 12.2.1

2016-02-29 Thread Sebastian Krupa (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171597#comment-15171597
 ] 

Sebastian Krupa commented on CXF-6777:
--

Without Weblogic - from standalone client - everything works perfectly.I've 
tried to explain this to Oracle support but they aren't listening :) and this 
is the reason why i've opened this "bug".

>  javax.net.ssl.SSLKeyException: Hostname verification failed on WLS 12.2.1
> --
>
> Key: CXF-6777
> URL: https://issues.apache.org/jira/browse/CXF-6777
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Reporter: Sebastian Krupa
> Attachments: SR Oracle.zip
>
>
> Could you help me - i have problem with Weblogic 12.2.1 when CXF 3.1.4 
> dynamic client tries to invoke SSL based web services.
> I have already reported it to Oracle support - but they said that it is CXF 
> problem not Weblogic, so here I am :) to ask you about it.
> I'm putting here reported issue(number in my oracle support SR 
> 3-11832157061), note *2029567.1* is error that has same exception like mine 
> by it has been fixed(Oracle says so) in WLS 12.1.3
> {panel:title=Fragments from Oracle support 
> page|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {color:red}We encountered a problem that is described in this note 
> *2029567.1* in one of our application that will be launched on WLS 12.2.1. 
> This error ocurs when dynamic Apache CXF client is invoked. Exception is like 
> follows:{color}
> <2015-12-07 11:55:09 CET> specified trustmanager validation status 0>
> <2015-12-07 11:55:09 CET>
> 
> <2015-12-07 11:55:09 CET>
> <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default 
> (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseadapter: 
> SSLENGINE: No trust failure, validateErr=0.>
> <2015-12-07 11:55:09 CET> hostname validation checks: test.osb.ibis.vip>
> <2015-12-07 11:55:09 CET> chain received from test.osb.ibis.vip - 172.16.200.115 failed hostname 
> verification check. Certificate contained test.osb.ibis.vip but check 
> expected test.osb.ibis.vip>
> <2015-12-07 11:55:09 CET> Verification failed for certificate with CommonName 'test.osb.ibis.vip' 
> against hostname: test.osb.ibis.vip>
> <2015-12-07 11:55:09 CET>
> <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default 
> (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseadapter: 
> SSLENGINE: Exception occurred during SSLEngine.wrap(ByteBuffer,ByteBuffer).
> javax.net.ssl.SSLKeyException: Hostname verification failed: 
> HostnameVerifier=weblogic.security.utils.SSLWLSHostnameVerifier, 
> hostname=test.osb.ibis.vip.
> at 
> weblogic.security.SSL.jsseadapter.JaSSLEngine.doPostHandshake(JaSSLEngine.java:677)
>  
> {color:red}Excpetion from admin server log:{color}
> ==AdminServer.log===
> <2015-12-07 11:55:09 CET>
>  <[ACTIVE] ExecuteThread: '0' for queue: 
> 'weblogic.kernel.Default (self-tuning)'> <> <> 
>  <1449485709084> 
> <[severity-value: 128] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > 
>  <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 
> 'weblogic.kernel.Default (self-tuning)',5,Pooled 
> Threads]]weblogic.security.SSL.jsseadapter: SSLENGINE: Exception occurred 
> during SSLEngine.unwrap(ByteBuffer,ByteBuffer[]).
> javax.net.ssl.SSLKeyException: Hostname verification failed: 
> HostnameVerifier=weblogic.security.utils.SSLWLSHostnameVerifier, 
> hostname=test.osb.ibis.vip.
> at 
> weblogic.security.SSL.jsseadapter.JaSSLEngine.doPostHandshake(JaSSLEngine.java:677)
> at 
> weblogic.security.SSL.jsseadapter.JaSSLEngine.doAction(JaSSLEngine.java:748)
> at weblogic.security.SSL.jsseadapter.JaSSLEngine.unwrap(JaSSLEngine.java:132)
> at weblogic.socket.JSSEFilterImpl.unwrap(JSSEFilterImpl.java:611)
> at 
> weblogic.socket.JSSEFilterImpl.unwrapAndHandleResults(JSSEFilterImpl.java:515)
> at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:98)
> at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:77)
> at weblogic.socket.JSSESocket.startHandshake(JSSESocket.java:240)
> at weblogic.net.http.HttpsClient.New(HttpsClient.java:574)
> at weblogic.net.http.HttpsClient.New(HttpsClient.java:545)
> at weblogic.net.http.HttpsURLConnection.connect(HttpsURLConnection.java:230)
> at 
> weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:685)
> at 
> weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:41)
> at org.apache.cxf.resource.URIResolver.tryFileSystem(URIResolver.java:184)
> at org.apache.cxf.resource.URIResolver.resolve(URIResolver.java:120)
> at 
> org.apache.cxf.resource.ExtendedURIResolver.resolve(ExtendedURIResolver.java:41)
> at 
> org.apache.cxf.transport.TransportURIRe

[jira] [Commented] (CXF-6777) javax.net.ssl.SSLKeyException: Hostname verification failed on WLS 12.2.1

2016-02-29 Thread Colm O hEigeartaigh (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171719#comment-15171719
 ] 

Colm O hEigeartaigh commented on CXF-6777:
--

You could try a standalone (non-CXF) test using the WebLogic HostnameVerifier + 
see if it fails.

Colm.

>  javax.net.ssl.SSLKeyException: Hostname verification failed on WLS 12.2.1
> --
>
> Key: CXF-6777
> URL: https://issues.apache.org/jira/browse/CXF-6777
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Reporter: Sebastian Krupa
> Attachments: SR Oracle.zip
>
>
> Could you help me - i have problem with Weblogic 12.2.1 when CXF 3.1.4 
> dynamic client tries to invoke SSL based web services.
> I have already reported it to Oracle support - but they said that it is CXF 
> problem not Weblogic, so here I am :) to ask you about it.
> I'm putting here reported issue(number in my oracle support SR 
> 3-11832157061), note *2029567.1* is error that has same exception like mine 
> by it has been fixed(Oracle says so) in WLS 12.1.3
> {panel:title=Fragments from Oracle support 
> page|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> {color:red}We encountered a problem that is described in this note 
> *2029567.1* in one of our application that will be launched on WLS 12.2.1. 
> This error ocurs when dynamic Apache CXF client is invoked. Exception is like 
> follows:{color}
> <2015-12-07 11:55:09 CET> specified trustmanager validation status 0>
> <2015-12-07 11:55:09 CET>
> 
> <2015-12-07 11:55:09 CET>
> <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default 
> (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseadapter: 
> SSLENGINE: No trust failure, validateErr=0.>
> <2015-12-07 11:55:09 CET> hostname validation checks: test.osb.ibis.vip>
> <2015-12-07 11:55:09 CET> chain received from test.osb.ibis.vip - 172.16.200.115 failed hostname 
> verification check. Certificate contained test.osb.ibis.vip but check 
> expected test.osb.ibis.vip>
> <2015-12-07 11:55:09 CET> Verification failed for certificate with CommonName 'test.osb.ibis.vip' 
> against hostname: test.osb.ibis.vip>
> <2015-12-07 11:55:09 CET>
> <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default 
> (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseadapter: 
> SSLENGINE: Exception occurred during SSLEngine.wrap(ByteBuffer,ByteBuffer).
> javax.net.ssl.SSLKeyException: Hostname verification failed: 
> HostnameVerifier=weblogic.security.utils.SSLWLSHostnameVerifier, 
> hostname=test.osb.ibis.vip.
> at 
> weblogic.security.SSL.jsseadapter.JaSSLEngine.doPostHandshake(JaSSLEngine.java:677)
>  
> {color:red}Excpetion from admin server log:{color}
> ==AdminServer.log===
> <2015-12-07 11:55:09 CET>
>  <[ACTIVE] ExecuteThread: '0' for queue: 
> 'weblogic.kernel.Default (self-tuning)'> <> <> 
>  <1449485709084> 
> <[severity-value: 128] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > 
>  <[Thread[[ACTIVE] ExecuteThread: '0' for queue: 
> 'weblogic.kernel.Default (self-tuning)',5,Pooled 
> Threads]]weblogic.security.SSL.jsseadapter: SSLENGINE: Exception occurred 
> during SSLEngine.unwrap(ByteBuffer,ByteBuffer[]).
> javax.net.ssl.SSLKeyException: Hostname verification failed: 
> HostnameVerifier=weblogic.security.utils.SSLWLSHostnameVerifier, 
> hostname=test.osb.ibis.vip.
> at 
> weblogic.security.SSL.jsseadapter.JaSSLEngine.doPostHandshake(JaSSLEngine.java:677)
> at 
> weblogic.security.SSL.jsseadapter.JaSSLEngine.doAction(JaSSLEngine.java:748)
> at weblogic.security.SSL.jsseadapter.JaSSLEngine.unwrap(JaSSLEngine.java:132)
> at weblogic.socket.JSSEFilterImpl.unwrap(JSSEFilterImpl.java:611)
> at 
> weblogic.socket.JSSEFilterImpl.unwrapAndHandleResults(JSSEFilterImpl.java:515)
> at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:98)
> at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:77)
> at weblogic.socket.JSSESocket.startHandshake(JSSESocket.java:240)
> at weblogic.net.http.HttpsClient.New(HttpsClient.java:574)
> at weblogic.net.http.HttpsClient.New(HttpsClient.java:545)
> at weblogic.net.http.HttpsURLConnection.connect(HttpsURLConnection.java:230)
> at 
> weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:685)
> at 
> weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:41)
> at org.apache.cxf.resource.URIResolver.tryFileSystem(URIResolver.java:184)
> at org.apache.cxf.resource.URIResolver.resolve(URIResolver.java:120)
> at 
> org.apache.cxf.resource.ExtendedURIResolver.resolve(ExtendedURIResolver.java:41)
> at 
> org.apache.cxf.transport.TransportURIResolver.resolve(TransportURIResolver.java:150)
> at 
> org.apache.cxf.wsdl11.CatalogWS

[jira] [Assigned] (CXF-6807) Broken svn URL in http://cxf.apache.org/docs/jax-rs-advanced-features.html

2016-02-29 Thread Colm O hEigeartaigh (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh reassigned CXF-6807:


Assignee: Colm O hEigeartaigh

> Broken svn URL in http://cxf.apache.org/docs/jax-rs-advanced-features.html
> --
>
> Key: CXF-6807
> URL: https://issues.apache.org/jira/browse/CXF-6807
> Project: CXF
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Tobias Schöneberg
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> In 
> http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Client
> it somewhere sais "[...]please see this beans.xml" where "beans.xml" is a 
> link to 
> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/resources/jms_server_config.xml
> that link is broken, the correct URL would be
> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/jms/jms_server_config.xml
> Regards, Tobi



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CXF-6807) Broken svn URL in http://cxf.apache.org/docs/jax-rs-advanced-features.html

2016-02-29 Thread Colm O hEigeartaigh (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh resolved CXF-6807.
--
Resolution: Fixed

> Broken svn URL in http://cxf.apache.org/docs/jax-rs-advanced-features.html
> --
>
> Key: CXF-6807
> URL: https://issues.apache.org/jira/browse/CXF-6807
> Project: CXF
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Tobias Schöneberg
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> In 
> http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Client
> it somewhere sais "[...]please see this beans.xml" where "beans.xml" is a 
> link to 
> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/resources/jms_server_config.xml
> that link is broken, the correct URL would be
> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/jms/jms_server_config.xml
> Regards, Tobi



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6807) Broken svn URL in http://cxf.apache.org/docs/jax-rs-advanced-features.html

2016-02-29 Thread Colm O hEigeartaigh (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed CXF-6807.


> Broken svn URL in http://cxf.apache.org/docs/jax-rs-advanced-features.html
> --
>
> Key: CXF-6807
> URL: https://issues.apache.org/jira/browse/CXF-6807
> Project: CXF
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Tobias Schöneberg
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> In 
> http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Client
> it somewhere sais "[...]please see this beans.xml" where "beans.xml" is a 
> link to 
> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/resources/jms_server_config.xml
> that link is broken, the correct URL would be
> http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/jms/jms_server_config.xml
> Regards, Tobi



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-6805) cxf-rt-transports-http adds Content-Type header to GET request

2016-02-29 Thread Sergey Beryozkin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171722#comment-15171722
 ] 

Sergey Beryozkin commented on CXF-6805:
---

thanks, I'll try to update the existing code a bit

> cxf-rt-transports-http adds Content-Type header to GET request
> --
>
> Key: CXF-6805
> URL: https://issues.apache.org/jira/browse/CXF-6805
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.0
>Reporter: Richard Stollar
>Priority: Minor
> Attachments: cxf-rt-transports-http.patch
>
>
> Then generating a web service client from WSDL the request sent to the server 
> has an additional Content-Type header.  Microsoft IIS 6.0 fails to process 
> these requests and returns 200-OK with empty body. 
> The Content-Type header should not be added to the http request when the 
> method is GET.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CXF-6805) cxf-rt-transports-http adds Content-Type header to GET request

2016-02-29 Thread Richard Stollar (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171140#comment-15171140
 ] 

Richard Stollar edited comment on CXF-6805 at 2/29/16 11:19 AM:


There's the problem. I tried to find somewhere where I could set the 
property but couldn't work it out.

When the header is set then this is the stack-trace I receive:

*Caused by: javax.xml.stream.XMLStreamException: ParseError at
[row,col]:[1,1]
Message: Premature end of file.
 at

com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:596)
 at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:1346)
 at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:1240)
 at org.apache.cxf.staxutils.StaxUtils.read(StaxUtils.java:1168)
 at

org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:219)
 ... 12 more*


*WSDLManagerImpl.loadDefinition(String url)*  must be where things start 
to go wrong. I couldn't find where the actual *Message* was being 
created in this flow. I'll look at it some more tomorrow.  I'm not 
really used to working with Maven projects and thus debugging this isn't 
something I have tried. I just rebuild the .jar files and re-run my test 
application with them - adding System.out.println() messages for debug.

Best regards,

Richard Stollar





was (Author: stollar):
There's the problem. I tried to find somewhere where I could set the 
property but couldn't work it out.

When the header is set then this is the stack-trace I receive:

*Caused by: javax.xml.stream.XMLStreamException: ParseError at
[row,col]:[1,1]
Message: Premature end of file.
 at

com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:596)
 at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:1346)
 at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:1240)
 at org.apache.cxf.staxutils.StaxUtils.read(StaxUtils.java:1168)
 at

org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:219)
 ... 12 more*


*WSDLManagerImpl.loadDefinition(String url)*  must be where things start 
to go wrong. I couldn't find where the actual *Message* was being 
created in this flow. I'll look at it some more tomorrow.  I'm not 
really used to working with Maven projects and thus debugging this isn't 
something I have tried. I just rebuild the .jar files and re-run my test 
application with them - adding System.out.println() messages for debug.

Best regards,

Richard Stollar
See: My Site 




> cxf-rt-transports-http adds Content-Type header to GET request
> --
>
> Key: CXF-6805
> URL: https://issues.apache.org/jira/browse/CXF-6805
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.0
>Reporter: Richard Stollar
>Priority: Minor
> Attachments: cxf-rt-transports-http.patch
>
>
> Then generating a web service client from WSDL the request sent to the server 
> has an additional Content-Type header.  Microsoft IIS 6.0 fails to process 
> these requests and returns 200-OK with empty body. 
> The Content-Type header should not be added to the http request when the 
> method is GET.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-6805) cxf-rt-transports-http adds Content-Type header to GET request

2016-02-29 Thread Sergey Beryozkin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171764#comment-15171764
 ] 

Sergey Beryozkin commented on CXF-6805:
---

The first commit went to the trunk, 
http://git-wip-us.apache.org/repos/asf/cxf/commit/a669400f

Going to merge to the branches next, what I suggested earlier (force the client 
GET code to set an empty request property just to make sure CT is not set) was 
sub-optimal

Thanks

> cxf-rt-transports-http adds Content-Type header to GET request
> --
>
> Key: CXF-6805
> URL: https://issues.apache.org/jira/browse/CXF-6805
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.0
>Reporter: Richard Stollar
>Priority: Minor
> Attachments: cxf-rt-transports-http.patch
>
>
> Then generating a web service client from WSDL the request sent to the server 
> has an additional Content-Type header.  Microsoft IIS 6.0 fails to process 
> these requests and returns 200-OK with empty body. 
> The Content-Type header should not be added to the http request when the 
> method is GET.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CXF-6805) cxf-rt-transports-http adds Content-Type header to GET request

2016-02-29 Thread Sergey Beryozkin (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin resolved CXF-6805.
---
   Resolution: Fixed
 Assignee: Sergey Beryozkin
Fix Version/s: 3.0.9
   3.1.6
   3.2.0

> cxf-rt-transports-http adds Content-Type header to GET request
> --
>
> Key: CXF-6805
> URL: https://issues.apache.org/jira/browse/CXF-6805
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.0
>Reporter: Richard Stollar
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.6, 3.0.9
>
> Attachments: cxf-rt-transports-http.patch
>
>
> Then generating a web service client from WSDL the request sent to the server 
> has an additional Content-Type header.  Microsoft IIS 6.0 fails to process 
> these requests and returns 200-OK with empty body. 
> The Content-Type header should not be added to the http request when the 
> method is GET.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-6805) cxf-rt-transports-http adds Content-Type header to GET request

2016-02-29 Thread Richard Stollar (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171809#comment-15171809
 ] 

Richard Stollar commented on CXF-6805:
--

Thanks Sergey - nice fix :)

Best regards,

Richard Stollar




> cxf-rt-transports-http adds Content-Type header to GET request
> --
>
> Key: CXF-6805
> URL: https://issues.apache.org/jira/browse/CXF-6805
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.0
>Reporter: Richard Stollar
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.6, 3.0.9
>
> Attachments: cxf-rt-transports-http.patch
>
>
> Then generating a web service client from WSDL the request sent to the server 
> has an additional Content-Type header.  Microsoft IIS 6.0 fails to process 
> these requests and returns 200-OK with empty body. 
> The Content-Type header should not be added to the http request when the 
> method is GET.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-6725) Remove deprecated JOSE configuration properties

2016-02-29 Thread Sergey Beryozkin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171830#comment-15171830
 ] 

Sergey Beryozkin commented on CXF-6725:
---

the 'list' signature properties for JWS JSON are also being deprecated (-3 to 
the overall list of properties) - the only difference between them and the 
'plain' properties is that a 'list' property value may contains either a 
'single value' String or a String with commas - when a user installs JwsJson 
readers/writers then these filters can expect that the 'plain' properties can 
be list properties.
Otherwise, we'd also have to add 3 more properties for JWE JSON filters, (+6 in 
total as far as 'list' properties are concerned vs -3)

> Remove deprecated JOSE configuration properties
> ---
>
> Key: CXF-6725
> URL: https://issues.apache.org/jira/browse/CXF-6725
> Project: CXF
>  Issue Type: Task
>  Components: JAX-RS, JAX-RS Security
>Reporter: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CXF-6725) Remove deprecated JOSE configuration properties

2016-02-29 Thread Sergey Beryozkin (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171830#comment-15171830
 ] 

Sergey Beryozkin edited comment on CXF-6725 at 2/29/16 12:55 PM:
-

the 'list' signature properties for JWS JSON are also being deprecated (-3 to 
the overall list of properties) - the only difference between them and the 
'plain' properties is that a 'list' property value may contain either a 'single 
value' String or a String with commas - when a user installs JwsJson 
readers/writers then these filters can expect that the 'plain' properties can 
be list properties.
Otherwise, we'd also have to add 3 more properties for JWE JSON filters, (+6 in 
total as far as 'list' properties are concerned vs -3)


was (Author: sergey_beryozkin):
the 'list' signature properties for JWS JSON are also being deprecated (-3 to 
the overall list of properties) - the only difference between them and the 
'plain' properties is that a 'list' property value may contains either a 
'single value' String or a String with commas - when a user installs JwsJson 
readers/writers then these filters can expect that the 'plain' properties can 
be list properties.
Otherwise, we'd also have to add 3 more properties for JWE JSON filters, (+6 in 
total as far as 'list' properties are concerned vs -3)

> Remove deprecated JOSE configuration properties
> ---
>
> Key: CXF-6725
> URL: https://issues.apache.org/jira/browse/CXF-6725
> Project: CXF
>  Issue Type: Task
>  Components: JAX-RS, JAX-RS Security
>Reporter: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-6808) Update JWS/JWE utils to load named properties

2016-02-29 Thread Sergey Beryozkin (JIRA) 
Sergey Beryozkin created CXF-6808:
-

 Summary: Update JWS/JWE utils to load named properties
 Key: CXF-6808
 URL: https://issues.apache.org/jira/browse/CXF-6808
 Project: CXF
  Issue Type: Improvement
  Components: JAX-RS, JAX-RS Security
Reporter: Sergey Beryozkin
Priority: Minor
 Fix For: 3.2.0


Right now JOSE utils load JWE/JWS properties identified by CXF message 
contextual properties such as RSSES_SIGNATURE(IN/OUT)_PROPS, etc.

In a complex system such as OIDC/etc it can become limiting, for example, the 
same endpoint may need to use different output/input signature/encryption tasks 
so with using a single properties file it may be difficult to identify which 
algorithm apply to which operation, etc...

Supporting loading named properties files will make it easier, with the system 
knowing in advance which properties file is needed for which operation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CXF-6808) Update JWS/JWE utils to load named properties

2016-02-29 Thread Sergey Beryozkin (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin updated CXF-6808:
--
Description: 
Right now JOSE utils load JWE/JWS properties identified by CXF message 
contextual properties such as RSSES_SIGNATURE(IN/OUT)_PROPS, etc.

In a complex system such as OIDC/etc it can become limiting, for example, the 
same endpoint may need to use different output/input signature/encryption tasks 
so with using a single properties file it may be difficult to identify which 
algorithm applies to which operation, etc...

Supporting loading named properties files will make it easier, with the system 
knowing in advance which properties file is needed for which operation

  was:
Right now JOSE utils load JWE/JWS properties identified by CXF message 
contextual properties such as RSSES_SIGNATURE(IN/OUT)_PROPS, etc.

In a complex system such as OIDC/etc it can become limiting, for example, the 
same endpoint may need to use different output/input signature/encryption tasks 
so with using a single properties file it may be difficult to identify which 
algorithm apply to which operation, etc...

Supporting loading named properties files will make it easier, with the system 
knowing in advance which properties file is needed for which operation


> Update JWS/JWE utils to load named properties
> -
>
> Key: CXF-6808
> URL: https://issues.apache.org/jira/browse/CXF-6808
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS, JAX-RS Security
>Reporter: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0
>
>
> Right now JOSE utils load JWE/JWS properties identified by CXF message 
> contextual properties such as RSSES_SIGNATURE(IN/OUT)_PROPS, etc.
> In a complex system such as OIDC/etc it can become limiting, for example, the 
> same endpoint may need to use different output/input signature/encryption 
> tasks so with using a single properties file it may be difficult to identify 
> which algorithm applies to which operation, etc...
> Supporting loading named properties files will make it easier, with the 
> system knowing in advance which properties file is needed for which operation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CXF-6085) JWE JSON Serialization

2016-02-29 Thread Sergey Beryozkin (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin updated CXF-6085:
--
Fix Version/s: 3.1.6
   3.2.0

Not sure if the tests will be added in time for 3.1.6, as only the filter 
prototypes have been added. May need to be pushed to 3.1.7. 

> JWE JSON Serialization
> --
>
> Key: CXF-6085
> URL: https://issues.apache.org/jira/browse/CXF-6085
> Project: CXF
>  Issue Type: New Feature
>  Components: JAX-RS, JAX-RS Security
>Reporter: Daniel Torkian
>Assignee: Sergey Beryozkin
>  Labels: jose, jwe, patch, serialization
> Fix For: 3.2.0, 3.1.6
>
> Attachments: initJSONJWE.txt
>
>
> https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#section-7.2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CXF-6808) Update JWS/JWE utils to load named properties

2016-02-29 Thread Sergey Beryozkin (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CXF-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin resolved CXF-6808.
---
   Resolution: Fixed
 Assignee: Sergey Beryozkin
Fix Version/s: 3.1.6

> Update JWS/JWE utils to load named properties
> -
>
> Key: CXF-6808
> URL: https://issues.apache.org/jira/browse/CXF-6808
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS, JAX-RS Security
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.6
>
>
> Right now JOSE utils load JWE/JWS properties identified by CXF message 
> contextual properties such as RSSES_SIGNATURE(IN/OUT)_PROPS, etc.
> In a complex system such as OIDC/etc it can become limiting, for example, the 
> same endpoint may need to use different output/input signature/encryption 
> tasks so with using a single properties file it may be difficult to identify 
> which algorithm applies to which operation, etc...
> Supporting loading named properties files will make it easier, with the 
> system knowing in advance which properties file is needed for which operation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FEDIZ-156) SAMLRequest ID must not start with a Number

2016-02-29 Thread Jan Bernhardt (JIRA) 
Jan Bernhardt created FEDIZ-156:
---

 Summary: SAMLRequest ID must not start with a Number
 Key: FEDIZ-156
 URL: https://issues.apache.org/jira/browse/FEDIZ-156
 Project: CXF-Fediz
  Issue Type: Bug
  Components: IDP
Affects Versions: 1.2.2
Reporter: Jan Bernhardt
Assignee: Jan Bernhardt
 Fix For: 1.3.0, 1.2.3


According to the XML Standard a xs:ID Element must not start with a number, but 
with a character or underscore instead.

http://www.datypic.com/sc/xsd/t-xsd_ID.html

Current ID generation produces also IDs that start with a number. This causes 
interoperability issues for example with the Siemens Entitlement Service.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-6682) NullpointerException in LinkBuilderImpl#getResolvedUri when only baseUri is set

2016-02-29 Thread Christoph Berg (JIRA) 

[ 
https://issues.apache.org/jira/browse/CXF-6682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173381#comment-15173381
 ] 

Christoph Berg commented on CXF-6682:
-

[~sergey_beryozkin] Can this ticket be closed? I mean, the commits are in for 
3.1.5, aren't they?

> NullpointerException in LinkBuilderImpl#getResolvedUri when only baseUri is 
> set
> ---
>
> Key: CXF-6682
> URL: https://issues.apache.org/jira/browse/CXF-6682
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.4
>Reporter: Christoph Berg
>
> The {{LinkBuilderImpl}} does not initialize its {{UriBuilder}} property with 
> a non null value causing a NullPointerException if calling its `build` method 
> after object construction.
> We have a testcase, which just calls {{baseUri}} followed by {{build}}. 
> Previously we used Jersey as JAX-RS implementation where this test works. 
> Looking at the code, Jersey initialises its property by just constructing 
> their implementation of `UriBuilder`.
> I would assume, that changing the line
> {code}
> private UriBuilder ub;
> {code}
> to
> {code}
> private UriBuilder ub = new UriBuilderImpl();
> {code}
> would suffice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-6809) SAMLRequest ID must not start with a Number

2016-02-29 Thread Jan Bernhardt (JIRA) 
Jan Bernhardt created CXF-6809:
--

 Summary: SAMLRequest ID must not start with a Number
 Key: CXF-6809
 URL: https://issues.apache.org/jira/browse/CXF-6809
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS Security
Affects Versions: 3.0.8, 3.1.5, 2.7.18
Reporter: Jan Bernhardt
Assignee: Jan Bernhardt
 Fix For: 3.2.0, 3.1.6


According to the XML Standard a xs:ID Element must not start with a number, but 
with a character or underscore instead.

http://www.datypic.com/sc/xsd/t-xsd_ID.html

Current ID generation in SAMLRequestBuilder is based on UUID generation only 
and can produce IDs that start with a number. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)