Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 3155 invoked from network); 28 Jul 2010 21:09:47 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Jul 2010 21:09:47 -0000 Received: (qmail 48935 invoked by uid 500); 28 Jul 2010 21:09:47 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 48762 invoked by uid 500); 28 Jul 2010 21:09:46 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 48754 invoked by uid 99); 28 Jul 2010 21:09:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jul 2010 21:09:46 +0000 X-ASF-Spam-Status: No, hits=-1997.8 required=10.0 tests=ALL_TRUSTED,HTML_MESSAGE,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 28 Jul 2010 21:09:45 +0000 Received: (qmail 3005 invoked by uid 99); 28 Jul 2010 21:09:25 -0000 Received: from localhost.apache.org (HELO nbwfhdavaleri) (127.0.0.1) (smtp-auth username dvaleri, mechanism login) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jul 2010 21:09:25 +0000 From: "David Valeri" To: Subject: WSS4JInInterceptor more lax in enforcing actions when encountering message containing a SOAP Fault Date: Wed, 28 Jul 2010 17:09:26 -0400 Message-ID: <001301cb2e99$2a4a56a0$7edf03e0$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01CB2E77.A338B6A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsumSbAiuoUQvlVQFaF5Z4KVRIVoA== Content-Language: en-us ------=_NextPart_000_0014_01CB2E77.A338B6A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lines 220-231 deal with the scenario where no security header is present at all. It would seem that the first if condition and the final else can be handled by checkActions (while taking into account the ignoreActions flag). The middle condition looks to be a potential security flaw in that we let unsecured faults through without honoring the user's actions configuration. If the user desires different actions in the fault scenario, they would configure different instances of this interceptor in the fault chains. What reason exists for this laxness with respect to action enforcement in the fault case? ------=_NextPart_000_0014_01CB2E77.A338B6A0--