ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Giger <gi...@apache.org>
Subject Re: svn commit: r1418741 - /webservices/wss4j/trunk/cxf-integration/src/main/java/org/swssf/cxfIntegration/interceptor/SecurityInInterceptor.java
Date Mon, 10 Dec 2012 18:17:17 GMT
Hi Dan,

I can confirm that CXF 2.6.3 and 2.6.4-SNAPSHOT (20121206) works
as expected. Sorry that I did not try out newer versions
before reporting the issue...

Many thanks,

Marc


On Mon, 10 Dec 2012 09:12:26 -0500
Daniel Kulp <dkulp@apache.org> wrote:

> 
> Barring some major issue discovered in the next couple hour, CXF
> 2.6.4 and 2.7.1 will be released in a few hours.   Any chance you can
> update your tests to one of those to check to see if the problem
> still exists.   There was some work done in 2.6.3 (and some more for
> 2.6.4) to make sure the readers are closed.
> 
> Dan
> 
> 
> On Dec 8, 2012, at 2:56 PM, giger@apache.org wrote:
> 
> > Author: giger
> > Date: Sat Dec  8 19:56:10 2012
> > New Revision: 1418741
> > 
> > URL: http://svn.apache.org/viewvc?rev=1418741&view=rev
> > Log:
> > Workaround: CXF seems not to call xmlstreamReader.close() which is
> > essential to complete security processing.
> > 
> > Modified:
> >    webservices/wss4j/trunk/cxf-integration/src/main/java/org/swssf/cxfIntegration/interceptor/SecurityInInterceptor.java
> > 
> > Modified:
> > webservices/wss4j/trunk/cxf-integration/src/main/java/org/swssf/cxfIntegration/interceptor/SecurityInInterceptor.java
> > URL:
> > http://svn.apache.org/viewvc/webservices/wss4j/trunk/cxf-integration/src/main/java/org/swssf/cxfIntegration/interceptor/SecurityInInterceptor.java?rev=1418741&r1=1418740&r2=1418741&view=diff
> > ==============================================================================
> > ---
> > webservices/wss4j/trunk/cxf-integration/src/main/java/org/swssf/cxfIntegration/interceptor/SecurityInInterceptor.java
> > (original) +++
> > webservices/wss4j/trunk/cxf-integration/src/main/java/org/swssf/cxfIntegration/interceptor/SecurityInInterceptor.java
> > Sat Dec  8 19:56:10 2012 @@ -22,8 +22,10 @@ import
> > org.apache.cxf.binding.soap.SoapF import
> > org.apache.cxf.binding.soap.SoapMessage; import
> > org.apache.cxf.binding.soap.interceptor.AbstractSoapInterceptor;
> > import org.apache.cxf.interceptor.Fault; +import
> > org.apache.cxf.interceptor.ServiceInvokerInterceptor; import
> > org.apache.cxf.interceptor.StaxInInterceptor;
> > 
> > +import org.apache.cxf.phase.Phase;
> > import org.apache.ws.security.common.ext.WSSecurityException;
> > import org.apache.ws.security.stax.WSSec;
> > import org.apache.ws.security.stax.ext.InboundWSSec;
> > @@ -84,6 +86,23 @@ public class SecurityInInterceptor exten
> >             newXmlStreamReader =
> > inboundWSSec.processInMessage(originalXmlStreamReader,
> > requestSecurityEvents, securityEventListener);
> > soapMessage.setContent(XMLStreamReader.class, newXmlStreamReader);
> > 
> > +            //workaround: CXF seems not to call
> > xmlstreamReader.close() which is essential to complete
> > +            //security processing. So we add another interceptor
> > which does it.
> > +            AbstractSoapInterceptor abstractSoapInterceptor = new
> > AbstractSoapInterceptor(Phase.PRE_INVOKE) { +
> > +                @Override
> > +                public void handleMessage(SoapMessage message)
> > throws Fault {
> > +                    XMLStreamReader xmlStreamReader =
> > message.getContent(XMLStreamReader.class);
> > +                    try {
> > +                        xmlStreamReader.close();
> > +                    } catch (XMLStreamException e) {
> > +                        throw new SoapFault("unexpected service
> > error", SoapFault.FAULT_CODE_SERVER);
> > +                    }
> > +                }
> > +            };
> > +
> > abstractSoapInterceptor.addBefore(ServiceInvokerInterceptor.class.getName());
> > +
> > soapMessage.getInterceptorChain().add(abstractSoapInterceptor); +
> >             //Warning: The exceptions which can occur here are not
> > security relevant exceptions but configuration-errors. //To catch
> > security relevant exceptions you have to catch them e.g.in the
> > FaultOutInterceptor. //Why? Because we do streaming security. This
> > interceptor doesn't handle the ws-security stuff but just
> > 
> > 
> 
> -- 
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message