Re: svn commit: r142447
thanks Dan
On 20/12/12 14:16, dk...@apache.org wrote:
Author: dkulp
Date: Thu Dec 20 14:16:01 2012
New Revision: 1424479
URL: http://svn.apache.org/viewvc?rev=1424479view=rev
Log:
[CXF-4714] Better fix by fixing the underlying jetty stream
Modified:
cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
Modified:
cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java?rev=1424479r1=1424478r2=1424479view=diff
==
---
cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
(original)
+++
cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
Thu Dec 20 14:16:01 2012
@@ -43,6 +43,7 @@ import org.apache.cxf.configuration.jsse
import org.apache.cxf.configuration.security.CertificateConstraintsType;
import org.apache.cxf.continuations.ContinuationProvider;
import org.apache.cxf.continuations.SuspendedInvocationException;
+import org.apache.cxf.helpers.IOUtils;
import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.io.CachedOutputStream;
import org.apache.cxf.io.CopyingOutputStream;
@@ -394,6 +395,7 @@ public class JettyHTTPDestination extend
static class JettyOutputStream extends FilterOutputStream implements
CopyingOutputStream {
final Output out;
+boolean written;
public JettyOutputStream(Output o) {
super(o);
out = o;
@@ -401,10 +403,21 @@ public class JettyHTTPDestination extend
@Override
public int copyFrom(InputStream in) throws IOException {
+if (written) {
+return IOUtils.copy(in, out);
+}
CountingInputStream c = new CountingInputStream(in);
out.sendContent(c);
return c.getCount();
}
+public void write(int b) throws IOException {
+written = true;
+out.write(b);
+}
+public void write(byte b[], int off, int len) throws IOException {
+written = true;
+out.write(b, off, len);
+}
}
static class CountingInputStream extends FilterInputStream {
int count;
Modified:
cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java?rev=1424479r1=1424478r2=1424479view=diff
==
---
cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
(original)
+++
cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
Thu Dec 20 14:16:01 2012
@@ -696,7 +696,7 @@ public abstract class AbstractHTTPDestin
written = true;
}
if (wrappedStream != null) {
-return IOUtils.copy(in, wrappedStream,
IOUtils.DEFAULT_BUFFER_SIZE);
+return IOUtils.copy(in, wrappedStream);
}
return IOUtils.copy(in, this, IOUtils.DEFAULT_BUFFER_SIZE);
}
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: CXF WSS4J signature validation problem.
I am operating in an environment where I communicate with web services to a group of organization with certs signed by a common CA. This set of organizations is mutable, and I don't want to manage my truststore everytime a new organization joins. However, per my understanding of the specifications when sending a signature it is allowable to only send the modulus/exponent of the public key. When I receive this message, the public key is not enough information to verify whether or not that public key was issued by the CA that I trust. I would like to write a custom validator which ensures the crypto aspect of this public key and the signature but stops short of trying to establish the trust of the public key. Is there a good resource or tutorial for how I could swap in a custom validator? I am not in love with this solution, however in my scenario the signature is backed by two-way SSL at the transport level, so I am ok with overlooking the trust of the public key at the signature level. Thank you! -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-WSS4J-signature-validation-problem-tp5719033p5720595.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: When to move JAX-RS Client implementation to the new module
On 13/12/12 12:01, Sergey Beryozkin wrote: Hi, I've opened CXF-4696 [1] to get the client implementation moved out of jax-rs frontend to its own module: to get the main module smaller, to let users avoid downloading extra baggage when no client code is utilized and in preparation for implementing JAX-RS 2.0 API (though I'm keen on keeping supporting WebClient API, with Proxy API having no challenge from 2.0 API :-)) I thought I'd wait till CXF 2.8.0-SNAPSHOT but then started changing my mind, the reason is that CXF 2.7.x users can expect minor dependency changes during the lifetime of CXF 2.7.x anyway, for example, jsr339-api-m10 dep will get replaced soon enough by jsr339-api-m13 - this for the most parts will be limited just to it, to the dependency update. Moving the client code to its own module will affect 2.7.x users exactly the same way, at some point, say, when migrating to CXF 2.7.2, they will need to add a new dependency but only if they also work with the client API. IMHO this is can be simpler, as opposed to having CXF 2.7.x and 2.8.x jaxrs frontends still depending till some point of time on the not finalized 2.0 API but having the client api located in different modules... After more consideration and some feedback it seems that that the best thing to do is to postpone it till a new 2.8.0-SNAPSHOT trunk is created; splitting the jaxrs frontend into 2 modules on the existing 2.7.x trunk (and soon to become a branch) appears to be a step too far... I'm still planning to do some refactoring on 2.7.x (to do with getting ProviderFactory class a bit more manageable given that now it has to deal with so many providers) but getting the modules split is definitely will be done in 2.8.x Updating to newer JAX-RS 2.0 milestone releases on 2.7.x is a slightly different issue - I'll start a new thread Thanks, Sergey [1] https://issues.apache.org/jira/browse/CXF-4696
Re: CXF WSS4J signature validation problem.
I am operating in an environment where I communicate with web services to a group of organization with certs signed by a common CA. This set of organizations is mutable, and I don't want to manage my truststore everytime a new organization joins. However, per my understanding of the specifications when sending a signature it is allowable to only send the modulus/exponent of the public key. When I receive this message, the public key is not enough information to verify whether or not that public key was issued by the CA that I trust. I would like to write a custom validator which ensures the crypto aspect of this public key and the signature but stops short of trying to establish the trust of the public key. Is there a good resource or tutorial for how I could swap in a custom validator? I am not in love with this solution, however in my scenario the signature is backed by two-way SSL at the transport level, so I am ok with overlooking the trust of the public key at the signature level. Thank you! -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-WSS4J-signature-validation-problem-tp5719033p5720594.html Sent from the cxf-dev mailing list archive at Nabble.com.
JAX-RS 2.0 and CXF 2.7.x
Hi At the moment CXF 2.7.2-SNAPSHOT depends on jsr339-api-m10 - this is quite close to the current JAX-RS 2.0 Snapshot API. ServiceMix spec jsr339-api-m10 (v 2.2.0) is also available. Next, jsr339-api-m13 and now jsr339-api-m15 are available in Central. The differences between jsr339-api-m10 and jsr339-api-m15 are quite minor at JAX-RS 2.0 API level - especially given that CXF does not implement yet the actual JAX-RS 2.0 client fluent API (though as I've mentioned earlier the async invoker and all 2.0 filters/interceptors are already supported). Users who started experimenting with AsyncResponse might see some differences - primarily to do with resume/cancel returning boolean instead of throwing exceptions, etc. Thought who might've started with DynamicFeature would be impacted most - but I honestly do not think anyone has started coding DynamicFeatures - we do not document it yet. I've been planning to get 2.7.x implementing final 2.0 API. It is important to note that the users migrating to 2.7.x are not expected to see any BC issues (and it was thanks to early 2.7.x users that we fixed some initial regressions/issues in 2.7.x). I've upgraded locally to jsr339-api-m15 and I'm eager to commit :-) The only 'side-effect' is that the users of next to be released CXF 2.7.2 would need to replace jsr339-api-m10 and jsr339-api-m15. Alternatively: we can keep jsr339-api-m10 in CXF 2.7.x for its lifetime, and get CXF 2.8.0-SNAPSHOT starting effectively with jsr339-api-m15 and commit to having CXF 2.8.0/1 get the final JAX-RS 2.0 done My preference is to get the 2.0 dependencies changed in 2.7.x or at least do the upgrade to m15 and stay there with the further updates done only in 2.8.x - however if there is some concern about it then the alternative (mentioned or others) can also work. Any comments ? Thanks, Sergey
Re: CXF WSS4J signature validation problem.
I got this spun up but CXF doesn't seem to be acknowledging that I have provided a custom interceptor. I use spring to provision endpoints, here is an excerpt of my service definition: jaxws:properties entry key=ws-security.callback-handler value=gov.hhs.fha.nhinc.callback.cxf.CXFSAMLCallbackHandler / entry key=ws-security.signature.properties value=keystore.properties / entry key=ws-security.encryption.properties value=truststore.properties / entry key=ws-security.signature.validator bean class=gov.hhs.fha.nhinc.callback.cxf.CONNECTSignatureTrustValidator / /entry /jaxws:properties However when I receive a web service message, I get the following stacktrace: [#|2012-12-20T14:49:02.901-0500|WARNING|glassfish3.1.2|org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor|_ThreadID=106;_ThreadName=Thread-2;|org.apache.ws.security.WSSecurityException: The security token could not be authenticated or authorized at org.apache.ws.security.validate.SignatureTrustValidator.validate(SignatureTrustValidator.java:86) at org.apache.ws.security.validate.SamlAssertionValidator.verifySignedAssertion(SamlAssertionValidator.java:121) at org.apache.ws.security.validate.SamlAssertionValidator.validate(SamlAssertionValidator.java:100) at org.apache.ws.security.processor.SAMLTokenProcessor.handleSAMLToken(SAMLTokenProcessor.java:188) at org.apache.ws.security.processor.SAMLTokenProcessor.handleToken(SAMLTokenProcessor.java:78) at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:396) at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:273) at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:95) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) It doesn't appear that my custom validator is being invoked. Any thoughts? -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-WSS4J-signature-validation-problem-tp5719033p5720609.html Sent from the cxf-dev mailing list archive at Nabble.com.
