You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by St...@faa.gov on 2014/05/05 18:03:36 UTC
Removing WS-Addressing headers on faults in CXF
Hi -
I have a requirement that when my service returns an InvalidSecurity
fault, that the fault includes as little information as possible.
Specifically, the fault shouldn't include any WS-Addressing headers, stack
traces, or a variety of other things. I have a CXF interceptor set up to
sanitize faults, which works great on the soap body. But no matter what I
do, my faults always end up with WS-Addressing headers.
The WS-Addressing headers are being added as a result of my output policy
in the WSDL. And for non-fault responses, or for faults that are not
InvalidSecurity, I need to include them. So for the InvalidSecurity case,
I'm attempting to remove them in a Fault Interceptor with code similar to:
if ( message.hasHeaders() ) {
if ( message.hasHeader(Names.WSA_TO_QNAME) ) {
log.info("Removing WS-A To");
Header hdr = message.getHeader(Names.WSA_TO_QNAME);
if ( message.getHeaders().remove(hdr) ) {
log.info("WS-A To successfully removed");
} else {
log.info("WS-A To NOT removed");
}
}
}
This code executes fine, and I see in my logs "Removing WS-A To", followed
by "WS-A To successfully removed". Then I see the fault, and it very
clearly has a wsa:To header in it.
I've tried playing around with the interceptor phase (it is currently in
Phase.MARSHALL) but that hasn't helped at all. Is there some other way to
remove headers during fault processing that anyone can recommend?
Thanx,
Stephen W. Chappell
Re: Removing WS-Addressing headers on faults in CXF
Posted by St...@faa.gov.
Thanx, Dan. I had it in my head that it needed to be in a later phase.
Moving it up to PRE_PROTOCOL works perfectly. Thanx!
Stephen W. Chappell
From: Daniel Kulp <dk...@apache.org>
ANG-B31, Information Security Branch
To: users@cxf.apache.org, Stephen CTR Chappell/ACT/CNTR/FAA@FAA,
Date: 05/05/2014 12:20 PM
Subject: Re: Removing WS-Addressing headers on faults in CXF
MARSHALL phase is definitely too late. This would likely need to be up
around the Phase.PRE_PROTOCOL phase for this to have an affect, definitely
before the WRITE phase. The headers should be added within the MAPCodec
interceptor in the PRE_PROTOCOL phase, but they are then written out
during the WRITE phase. Thus, you need to put your code in there
someplace.
Dan
On May 5, 2014, at 12:03 PM, Stephen.CTR.Chappell@faa.gov wrote:
> Hi -
>
> I have a requirement that when my service returns an InvalidSecurity
> fault, that the fault includes as little information as possible.
> Specifically, the fault shouldn't include any WS-Addressing headers,
stack
> traces, or a variety of other things. I have a CXF interceptor set up to
> sanitize faults, which works great on the soap body. But no matter what
I
> do, my faults always end up with WS-Addressing headers.
>
> The WS-Addressing headers are being added as a result of my output
policy
> in the WSDL. And for non-fault responses, or for faults that are not
> InvalidSecurity, I need to include them. So for the InvalidSecurity
case,
> I'm attempting to remove them in a Fault Interceptor with code similar
to:
>
> if ( message.hasHeaders() ) {
> if ( message.hasHeader(Names.WSA_TO_QNAME) ) {
> log.info("Removing WS-A To");
> Header hdr = message.getHeader(Names.WSA_TO_QNAME);
>
> if ( message.getHeaders().remove(hdr) ) {
> log.info("WS-A To successfully removed");
> } else {
> log.info("WS-A To NOT removed");
> }
> }
> }
>
> This code executes fine, and I see in my logs "Removing WS-A To",
followed
> by "WS-A To successfully removed". Then I see the fault, and it very
> clearly has a wsa:To header in it.
>
> I've tried playing around with the interceptor phase (it is currently in
> Phase.MARSHALL) but that hasn't helped at all. Is there some other way
to
> remove headers during fault processing that anyone can recommend?
>
> Thanx,
>
>
> Stephen W. Chappell
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Removing WS-Addressing headers on faults in CXF
Posted by Daniel Kulp <dk...@apache.org>.
MARSHALL phase is definitely too late. This would likely need to be up around the Phase.PRE_PROTOCOL phase for this to have an affect, definitely before the WRITE phase. The headers should be added within the MAPCodec interceptor in the PRE_PROTOCOL phase, but they are then written out during the WRITE phase. Thus, you need to put your code in there someplace.
Dan
On May 5, 2014, at 12:03 PM, Stephen.CTR.Chappell@faa.gov wrote:
> Hi -
>
> I have a requirement that when my service returns an InvalidSecurity
> fault, that the fault includes as little information as possible.
> Specifically, the fault shouldn't include any WS-Addressing headers, stack
> traces, or a variety of other things. I have a CXF interceptor set up to
> sanitize faults, which works great on the soap body. But no matter what I
> do, my faults always end up with WS-Addressing headers.
>
> The WS-Addressing headers are being added as a result of my output policy
> in the WSDL. And for non-fault responses, or for faults that are not
> InvalidSecurity, I need to include them. So for the InvalidSecurity case,
> I'm attempting to remove them in a Fault Interceptor with code similar to:
>
> if ( message.hasHeaders() ) {
> if ( message.hasHeader(Names.WSA_TO_QNAME) ) {
> log.info("Removing WS-A To");
> Header hdr = message.getHeader(Names.WSA_TO_QNAME);
>
> if ( message.getHeaders().remove(hdr) ) {
> log.info("WS-A To successfully removed");
> } else {
> log.info("WS-A To NOT removed");
> }
> }
> }
>
> This code executes fine, and I see in my logs "Removing WS-A To", followed
> by "WS-A To successfully removed". Then I see the fault, and it very
> clearly has a wsa:To header in it.
>
> I've tried playing around with the interceptor phase (it is currently in
> Phase.MARSHALL) but that hasn't helped at all. Is there some other way to
> remove headers during fault processing that anyone can recommend?
>
> Thanx,
>
>
> Stephen W. Chappell
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com