[jira] [Commented] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701766#comment-15701766 ] Sergey Beryozkin commented on CXF-7137: --- I've re-read your comments and checked some resources and I think I understand how the whole process works now, thanks. I've added a Map of SecuritySchemeDefinitions property to Swagger2Feature to make it easier to set these definitions. But this issue is really about ensuring Swagger UI sends correct client_id/etc to the OAuth2 authorization service. Swagger2Feature does not ship SwaggerUI. I believe you'd need to expand swagger UI like this: https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/jax_rs/description_swagger/pom.xml#L63 but also ship a custom index.html where you will define clientId/etc variables for swagger-oauth.js to correctly identify them. I've just checked swagger-ui-2.1.8-M1, initOAuth is commented out in index.html. So I think it is the only way right - ship the custom index.html. IMHO the better option is for SwaggerUI (swagger-oauth.js) to auto-enable the text fields which will let the user enter client_id/etc if OAuth2 security scheme definition is available to avoid customizing index.html - please consider creating a pull request against Swagger UI. I honestly do not see what else we can do at the CXF level apart from the update I did to make it easier to add the security definitions. > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. >Assignee: Sergey Beryozkin > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701766#comment-15701766 ] Sergey Beryozkin edited comment on CXF-7137 at 11/28/16 11:41 AM: -- I've re-read your comments and checked some resources and I think I understand how the whole process works now, thanks. I've added a Map of SecuritySchemeDefinitions property to Swagger2Feature to make it easier to set these definitions. But this issue is really about ensuring Swagger UI sends correct client_id/etc to the OAuth2 authorization service. Swagger2Feature does not ship SwaggerUI. I believe you'd need to expand swagger UI like this: https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/jax_rs/description_swagger/pom.xml#L63 but also ship a custom index.html where you will define clientId/etc variables for swagger-oauth.js to correctly identify them. I've just checked swagger-ui-2.1.8-M1, initOAuth is commented out in index.html. So I think it is the only way right now - ship the custom index.html. IMHO the better option is for SwaggerUI (swagger-oauth.js) to auto-enable the text fields which will let the user enter client_id/etc if OAuth2 security scheme definition is available to avoid customizing index.html - please consider creating a pull request against Swagger UI. I honestly do not see what else we can do at the CXF level apart from the update I did to make it easier to add the security definitions. was (Author: sergey_beryozkin): I've re-read your comments and checked some resources and I think I understand how the whole process works now, thanks. I've added a Map of SecuritySchemeDefinitions property to Swagger2Feature to make it easier to set these definitions. But this issue is really about ensuring Swagger UI sends correct client_id/etc to the OAuth2 authorization service. Swagger2Feature does not ship SwaggerUI. I believe you'd need to expand swagger UI like this: https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/jax_rs/description_swagger/pom.xml#L63 but also ship a custom index.html where you will define clientId/etc variables for swagger-oauth.js to correctly identify them. I've just checked swagger-ui-2.1.8-M1, initOAuth is commented out in index.html. So I think it is the only way right - ship the custom index.html. IMHO the better option is for SwaggerUI (swagger-oauth.js) to auto-enable the text fields which will let the user enter client_id/etc if OAuth2 security scheme definition is available to avoid customizing index.html - please consider creating a pull request against Swagger UI. I honestly do not see what else we can do at the CXF level apart from the update I did to make it easier to add the security definitions. > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. >Assignee: Sergey Beryozkin > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7153) requestSecurityToken(String appliesTo) hangs with no response
[ https://issues.apache.org/jira/browse/CXF-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701775#comment-15701775 ] Colm O hEigeartaigh commented on CXF-7153: -- If you use tcpdump or some such application, can you see the SOAP Request from the STSClient being sent on the wire? > requestSecurityToken(String appliesTo) hangs with no response > -- > > Key: CXF-7153 > URL: https://issues.apache.org/jira/browse/CXF-7153 > Project: CXF > Issue Type: Bug >Reporter: rohan sharma > Fix For: 2.7.12 > > > Hi, > I am using STS Client to request security token from ADFS and calling method > requestSecurityToken(String appliesTo) . > This call hangs with no response, there is no visible error in log and there > is no response. > When i debug i can see that it is sending the request and then waiting for > response in the method doReceiveResponse [Class HttpRequestExecutor] and > internally it calls method readLine(Final CharArrayBuffer buffer) [Class > LoggingSessionInputBuffer] and it hangs at code "this.in.readLine(buffer)". > There is native code after this from where the code never returns. > I could not find any issue with my request that i am sending. > I print the request generated from stsClient in log and i am able to get > response from the same request through SOAPUI from the same machine. > I have also seen ADFS logs, the request is not reaching ADFS there is no > event in ADFS when i send request through STSClient. > Version - cxf-rt-ws-security-2.7.12 > Do you know what is the problem here? Any solution to this or any way to > track it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-7154) WSDL2JAVA Allows Unsafe Characters in to Generated Javadocs
[ https://issues.apache.org/jira/browse/CXF-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-7154: Assignee: Colm O hEigeartaigh > WSDL2JAVA Allows Unsafe Characters in to Generated Javadocs > --- > > Key: CXF-7154 > URL: https://issues.apache.org/jira/browse/CXF-7154 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 3.2.0, 3.1.8 >Reporter: Owen Farrell >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: EchoEndpoint.java, SAMPLE.wsdl > > > When generating client stubs from WSDLs, the wsdl2java tool does not account > for unsafe characters in the documentation tags provided by the WSDL. As a > result, the javadoc tool generates unnecessary errors when run over sources > generated by CXF. > See attached WSDL and generated class for examples. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7154) WSDL2JAVA Allows Unsafe Characters in to Generated Javadocs
[ https://issues.apache.org/jira/browse/CXF-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7154: - Fix Version/s: 3.0.12 3.1.9 3.2.0 > WSDL2JAVA Allows Unsafe Characters in to Generated Javadocs > --- > > Key: CXF-7154 > URL: https://issues.apache.org/jira/browse/CXF-7154 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 3.2.0, 3.1.8 >Reporter: Owen Farrell >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: EchoEndpoint.java, SAMPLE.wsdl > > > When generating client stubs from WSDLs, the wsdl2java tool does not account > for unsafe characters in the documentation tags provided by the WSDL. As a > result, the javadoc tool generates unnecessary errors when run over sources > generated by CXF. > See attached WSDL and generated class for examples. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7153) requestSecurityToken(String appliesTo) hangs with no response
[ https://issues.apache.org/jira/browse/CXF-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701981#comment-15701981 ] rohan sharma commented on CXF-7153: --- yes in Apache wire logs i can see the SOAP request and if i put this request in SOAPUI it works perfectly however i don't see any event in ADFS. > requestSecurityToken(String appliesTo) hangs with no response > -- > > Key: CXF-7153 > URL: https://issues.apache.org/jira/browse/CXF-7153 > Project: CXF > Issue Type: Bug >Reporter: rohan sharma > Fix For: 2.7.12 > > > Hi, > I am using STS Client to request security token from ADFS and calling method > requestSecurityToken(String appliesTo) . > This call hangs with no response, there is no visible error in log and there > is no response. > When i debug i can see that it is sending the request and then waiting for > response in the method doReceiveResponse [Class HttpRequestExecutor] and > internally it calls method readLine(Final CharArrayBuffer buffer) [Class > LoggingSessionInputBuffer] and it hangs at code "this.in.readLine(buffer)". > There is native code after this from where the code never returns. > I could not find any issue with my request that i am sending. > I print the request generated from stsClient in log and i am able to get > response from the same request through SOAPUI from the same machine. > I have also seen ADFS logs, the request is not reaching ADFS there is no > event in ADFS when i send request through STSClient. > Version - cxf-rt-ws-security-2.7.12 > Do you know what is the problem here? Any solution to this or any way to > track it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7000) Allow logging to be enabled on-the-fly
[
https://issues.apache.org/jira/browse/CXF-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702119#comment-15702119
]
Rostislav Svoboda commented on CXF-7000:
To be able to enable / disable live logging I need:
* set org.apache.cxf.logging.enabled to [{{true}} or
{{pretty}}|https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/bus/extension/ExtensionManagerBus.java#L68-L72]
to [enable
{{LoggingFeature}}|https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/bus/extension/ExtensionManagerBus.java#L112]
or
* configure usage of {{LoggingInInterceptor}} or/and {{LoggingOutInterceptor}}
on endpoint (or client side)
After that I can dynamically enable/disable logging via
{{org.apache.cxf.logging.enable}} contextual property
Is it correct summary?
> Allow logging to be enabled on-the-fly
> --
>
> Key: CXF-7000
> URL: https://issues.apache.org/jira/browse/CXF-7000
> Project: CXF
> Issue Type: Improvement
> Components: Core, logging
>Affects Versions: 3.1.7
>Reporter: Ingo Weiss
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.8
>
>
> Allow the logging feature to be enabled on-the-fly without restarting the bus.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7154) WSDL2JAVA Allows Unsafe Characters in to Generated Javadocs
[ https://issues.apache.org/jira/browse/CXF-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702132#comment-15702132 ] ASF GitHub Bot commented on CXF-7154: - Github user asfgit closed the pull request at: https://github.com/apache/cxf/pull/206 > WSDL2JAVA Allows Unsafe Characters in to Generated Javadocs > --- > > Key: CXF-7154 > URL: https://issues.apache.org/jira/browse/CXF-7154 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 3.2.0, 3.1.8 >Reporter: Owen Farrell >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: EchoEndpoint.java, SAMPLE.wsdl > > > When generating client stubs from WSDLs, the wsdl2java tool does not account > for unsafe characters in the documentation tags provided by the WSDL. As a > result, the javadoc tool generates unnecessary errors when run over sources > generated by CXF. > See attached WSDL and generated class for examples. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7000) Allow logging to be enabled on-the-fly
[ https://issues.apache.org/jira/browse/CXF-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702147#comment-15702147 ] Sergey Beryozkin commented on CXF-7000: --- It does not matter how LoggingFeature was created. The important thing is that it will be logging as long as 'org.apache.cxf.logging.enable' is not explicitly set to 'false' > Allow logging to be enabled on-the-fly > -- > > Key: CXF-7000 > URL: https://issues.apache.org/jira/browse/CXF-7000 > Project: CXF > Issue Type: Improvement > Components: Core, logging >Affects Versions: 3.1.7 >Reporter: Ingo Weiss >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8 > > > Allow the logging feature to be enabled on-the-fly without restarting the bus. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7157) Support the client side bean validation for CXF client proxies
Sergey Beryozkin created CXF-7157: - Summary: Support the client side bean validation for CXF client proxies Key: CXF-7157 URL: https://issues.apache.org/jira/browse/CXF-7157 Project: CXF Issue Type: New Feature Components: Core, JAX-RS Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor Fix For: 3.2.0, 3.1.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7157) Support the client side bean validation for CXF client proxies
[ https://issues.apache.org/jira/browse/CXF-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7157. --- Resolution: Fixed > Support the client side bean validation for CXF client proxies > > > Key: CXF-7157 > URL: https://issues.apache.org/jira/browse/CXF-7157 > Project: CXF > Issue Type: New Feature > Components: Core, JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.9 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7154) WSDL2JAVA Allows Unsafe Characters in to Generated Javadocs
[ https://issues.apache.org/jira/browse/CXF-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7154. -- Resolution: Fixed > WSDL2JAVA Allows Unsafe Characters in to Generated Javadocs > --- > > Key: CXF-7154 > URL: https://issues.apache.org/jira/browse/CXF-7154 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 3.2.0, 3.1.8 >Reporter: Owen Farrell >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: EchoEndpoint.java, SAMPLE.wsdl > > > When generating client stubs from WSDLs, the wsdl2java tool does not account > for unsafe characters in the documentation tags provided by the WSDL. As a > result, the javadoc tool generates unnecessary errors when run over sources > generated by CXF. > See attached WSDL and generated class for examples. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702385#comment-15702385 ] Alexander K. commented on CXF-7137: --- Thanks, I will follow you suggestion to consider creating a request for Swagger UI. > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. >Assignee: Sergey Beryozkin > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7119) Introduce a JAX-RS client provider for catching technical exceptions (e.g. IOException)
[ https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7119. --- Resolution: Fixed > Introduce a JAX-RS client provider for catching technical exceptions (e.g. > IOException) > --- > > Key: CXF-7119 > URL: https://issues.apache.org/jira/browse/CXF-7119 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.1.3 >Reporter: Jörg Hohwiller >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9 > > > When using CXF for REST/JAX-RS service clients I quickly noticed that I need > to tweak the error handling. My services use an ExceptionMapper that provides > error details via JSON result payload. Hence I want to access this and render > an exception with further details and more context information what works > fine with ResponseExceptionMapper. > However, when a technical error (IOException such as unkown host, connection > refused, timeout, etc.) occurrs I only get generic errors from CXF client > (org.apache.cxf.interceptor.Fault: Could not send Message.). This is > undesired but unfortunately my custom ResponseExceptionMapper is never called > for such technical errors. There seems to be no way to archive my goal with > CXF itself. I could only wrap the client again with a custom written dynamic > proxy to reach my goal. > It seems that CXF hardwires this behaviour: > https://github.com/apache/cxf/blob/master/rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/AbstractClient.java#L596 > https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/interceptor/MessageSenderInterceptor.java#L64 > It would be awesome if in such case ResponseExceptionMapper would also be > applied so I have the chance to interfere and produce better exceptions (e.g. > with a message containing the name of the application/microservice that could > not be called, the URL, etc.) for my individual needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7137. --- Resolution: Resolved Fix Version/s: 3.1.9 3.2.0 Thanks, I'll have to mark this issue as Won't Fix even though we did update Swagger2Feature a bit - but that update will not help with modifying Swagger UI resources. I guess that NET project is probably embedding SwaggerUI resources, possibly with a custom index.html, etc... > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9 > > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702477#comment-15702477 ] Sergey Beryozkin commented on CXF-7137: --- I marked it as Resolved initially and forgot to change. May be I will keep it as is, assuming Resolved does not mean 'Fixed' :-) > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9 > > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6930) Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload while logging it
[
https://issues.apache.org/jira/browse/CXF-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702774#comment-15702774
]
Tobias Schöneberg commented on CXF-6930:
Thx for the info, I'm going to try it out this week and report
> Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload
> while logging it
> ---
>
> Key: CXF-6930
> URL: https://issues.apache.org/jira/browse/CXF-6930
> Project: CXF
> Issue Type: Bug
> Components: JMS
>Affects Versions: 3.1.6
>Reporter: Tobias Schöneberg
>Assignee: Daniel Kulp
> Fix For: 3.1.8
>
>
> Hi,
> I think we stumbled over a problem with cxf and the JMS-transport,
> if the {{LoggingFeature}} is used to log incoming response messages.
> The problem is that sometimes, {{ClientProxyImpl.invoke(...)}} returns
> {{null}},
> but from the logged message payload, it's clear that there is a not-null
> response payload coming from the sever.
> I believe, I just figured out that it is in fact the logging of that very
> payload which causes {{ClientProxyImpl.invoke(...)}} to return {{null}}.
> How?
> There is a race between the actual "client thread" which waited for the
> server's response
> (i.e. {{exchange.wait()}} in {{JMSConduit.sendAndReceiveMessage(...)}} )
> until notified by the ActiveMQ Session Task thread
> (i.e. {{exchange.notifyAll()}} in {{JMSConduit.processReplyMessage(...)}} )
> one one side and the ActiveMQ Session Task thread itself on the other side.
> Once the client thread is notified, it goes on with {{preProcessResult(...)}}
> and {{handleResponse(...)}} and somewhere in there the message's
> {{ByteArrayStream}} is read and the return object is created.
> However, at the same time, back in the ActiveMQ thread, the interceptor chain
> is run.
> In my case it contains the {{LoggingInInterceptor}} which accesses the
> message's *same* {{ByteArrayInputStream}}, in the method
> {{LoggingInInterceptor.logInputStream(...)}} ).
> Now, in {{logInputStream(...)}}, we have
> {code:java}
> IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);
> bos.flush();
> bis = new SequenceInputStream(bos.getInputStream(), bis);
> // restore the delegating input stream or the input stream
> if (is instanceof DelegatingInputStream) {
> ((DelegatingInputStream)is).setInputStream(bis);
> } else {
> message.setContent(InputStream.class, bis);
> }
> {code}
> My problem happens if the client thread tries to read the message while
> "{{bis}}" was read, but not yet restored. During that time, "{{bis}}" is
> closed for the in the client thread and it will skip over it (or throw an
> Exception, based on its config).
> My current best and maybe naive guess on how to solve this is to change the
> method {{JMSConduit.processReplyMessage(...)}}
> and execute the if-block around {{exchange.notifyAll();}} only after the
> if-block around {{incomingObserver.onMessage(exchange.getInMessage());}}
> WDYT?
> Best reagards
> Tobias
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7039) JAX-RS Security SAML web SSO consumer service can not validate SAML response behind reverse proxy
[ https://issues.apache.org/jira/browse/CXF-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15703316#comment-15703316 ] PHILIP edited comment on CXF-7039 at 11/28/16 10:19 PM: We encountered this issue during deployment of our application and found this fix. In our case the addresses differ in that the protocol changes depending on if the reverse proxy is between insecure and secure zones (http vs https respectively). An outstanding question regarding this fix is how it fundamentally changes the validation which occurs when the pre-configured value is used versus the message's actual destination. Can you provide an explanation addressing how both approaches are compliant with the SAML protocol? Thank you. was (Author: philco): We encountered this issue during deployment of our application and found this fix. In our case the addresses differ in that the protocol changes depeding on if the reverse proxy is between insecure and secure zones (http vs https respectively). An outstanding question regarding this fix is how it fundamentally changes the validation which occurs when the pre-configured value is used versus the message's actual destination. Can you provide an explanation addressing how both approaches are compliant with the SAML protocol? Thank you. > JAX-RS Security SAML web SSO consumer service can not validate SAML response > behind reverse proxy > - > > Key: CXF-7039 > URL: https://issues.apache.org/jira/browse/CXF-7039 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.0.9 > Environment: JRE 1.8.0_101-b13 >Reporter: Michal Sabo >Assignee: Colm O hEigeartaigh > Fix For: 3.2.0, 3.1.8, 3.0.11 > > > During the SAML web SSO processing, the RequestAssertionConsumerService > validates the request with the > org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator using a wrong > assertionConsumerURL. > The SAML request (org.opensaml.saml2.core.AuthnRequest) is configured with > the serviceURL taken as the > org.apache.cxf.rs.security.saml.sso.AbstractServiceProviderFilter.assertionConsumerServiceAddress > property, however the > org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator is bootstrapped > with the following consumer URL: > ssoResponseValidator.setAssertionConsumerURL(messageContext.getUriInfo().getAbsolutePath().toString()); > This particularly makes a problem when serving the application behind a > reverse proxy since the absolutePath taken from messageVontext's uriInfo is > different than the configured one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7039) JAX-RS Security SAML web SSO consumer service can not validate SAML response behind reverse proxy
[ https://issues.apache.org/jira/browse/CXF-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15703316#comment-15703316 ] PHILIP commented on CXF-7039: - We encountered this issue during deployment of our application and found this fix. In our case the addresses differ in that the protocol changes depeding on if the reverse proxy is between insecure and secure zones (http vs https respectively). An outstanding question regarding this fix is how it fundamentally changes the validation which occurs when the pre-configured value is used versus the message's actual destination. Can you provide an explanation addressing how both approaches are compliant with the SAML protocol? Thank you. > JAX-RS Security SAML web SSO consumer service can not validate SAML response > behind reverse proxy > - > > Key: CXF-7039 > URL: https://issues.apache.org/jira/browse/CXF-7039 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.0.9 > Environment: JRE 1.8.0_101-b13 >Reporter: Michal Sabo >Assignee: Colm O hEigeartaigh > Fix For: 3.2.0, 3.1.8, 3.0.11 > > > During the SAML web SSO processing, the RequestAssertionConsumerService > validates the request with the > org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator using a wrong > assertionConsumerURL. > The SAML request (org.opensaml.saml2.core.AuthnRequest) is configured with > the serviceURL taken as the > org.apache.cxf.rs.security.saml.sso.AbstractServiceProviderFilter.assertionConsumerServiceAddress > property, however the > org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator is bootstrapped > with the following consumer URL: > ssoResponseValidator.setAssertionConsumerURL(messageContext.getUriInfo().getAbsolutePath().toString()); > This particularly makes a problem when serving the application behind a > reverse proxy since the absolutePath taken from messageVontext's uriInfo is > different than the configured one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
