Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 95061 invoked from network); 6 Apr 2011 14:01:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Apr 2011 14:01:14 -0000 Received: (qmail 9741 invoked by uid 500); 6 Apr 2011 14:01:13 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 9675 invoked by uid 500); 6 Apr 2011 14:01:13 -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 9667 invoked by uid 99); 6 Apr 2011 14:01:13 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Apr 2011 14:01:13 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.85.173.253] (HELO server.dankulp.com) (64.85.173.253) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Apr 2011 14:01:06 +0000 Received: by server.dankulp.com (Postfix, from userid 5000) id 61C5C188EF5; Wed, 6 Apr 2011 10:00:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter-dev@cxf.apache.org.vZ6P57m5sp Received: from dilbert.dankulp.com (c-24-91-72-253.hsd1.ma.comcast.net [24.91.72.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTPSA id 04080188B44; Wed, 6 Apr 2011 10:00:43 -0400 (EDT) From: Daniel Kulp To: dev@cxf.apache.org Subject: Re: svn commit: r1089385 - /cxf/trunk/api/src/main/java/org/apache/cxf/interceptor/Fault.java Date: Wed, 6 Apr 2011 10:00:41 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38; KDE/4.6.1; x86_64; ; ) Cc: Christian Schneider References: <20110406102142.73DA42388A9B@eris.apache.org> <201104060635.03926.dkulp@apache.org> <4D9C6F32.80101@die-schneider.net> In-Reply-To: <4D9C6F32.80101@die-schneider.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201104061000.41802.dkulp@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-102.9 required=3.0 tests=ALL_TRUSTED,BAYES_00, SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.3.1 On Wednesday 06 April 2011 9:48:34 AM Christian Schneider wrote: > Hi Dan, > > I think the cause of the exception is very import to diagnose problems > but I also understand that the leakage of security information is a big > problem. > > So how about introducing a config setting that controls if the cause and > stacktrace is transmitted. > So for development systems the users may set the flag to true and for > production systems they set it to false. There is already some level of support for this. If you add "faultStackTraceEnabled" "true" as a property (endpoint property, bus property, etc...), then the stack trace is added to the details for the fault. That said, it's likely not tested very well (and likely not documented) and I'm not sure if it digs through all the causes or not or if it's just the stack trace for the root cause. I think it's ALSO only for Soap 1.1. However, I'd definitely support updates to that code to push it into a common superclass of the two SoapFaultOut interceptors or into the FaultOutInterceptor in rt/core and update it to be more flexible about sending the internal causes and such. Dan > > Christian > > Am 06.04.2011 12:35, schrieb Daniel Kulp: > > I think I'm -1 to this change. To me, this looks like it may leak > > security information and such to the client. > > > > The only message sent back to the client should be the top level message. > > The "causes" should be logged server side and not reflected back. If > > there are certain places where we CAN send back a specific cause, we > > should just do that. We specifically don't send the stacks and such > > back to the client (by default) exactly for that reason. > > > > > > In the case of the SAAJIn, if it's an XMLStreamException, just do > > something like: > > > > throw new SoapFault(new org.apache.cxf.common.i18n.Message( > > > > e.getMessage(), BUNDLE), e, message > > .getVersion().getSender()); > > > > Dan > > > > On Wednesday 06 April 2011 6:21:42 AM ningjiang@apache.org wrote: > >> Author: ningjiang > >> Date: Wed Apr 6 10:21:42 2011 > >> New Revision: 1089385 > >> > >> URL: http://svn.apache.org/viewvc?rev=1089385&view=rev > >> Log: > >> CXF-3442 Fault should not swallow the cause exception message > >> > >> Modified: > >> cxf/trunk/api/src/main/java/org/apache/cxf/interceptor/Fault.java > >> > >> Modified: > >> cxf/trunk/api/src/main/java/org/apache/cxf/interceptor/Fault.java URL: > >> http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/ > >> in terceptor/Fault.java?rev=1089385&r1=1089384&r2=1089385&view=diff > >> ======================================================================= > >> === ==== --- > >> cxf/trunk/api/src/main/java/org/apache/cxf/interceptor/Fault.java > >> (original) +++ > >> cxf/trunk/api/src/main/java/org/apache/cxf/interceptor/Fault.java Wed > >> Apr 6 10:21:42 2011 @@ -44,7 +44,13 @@ public class Fault extends > >> UncheckedExce > >> > >> public Fault(Message message, Throwable throwable) { > >> > >> super(message, throwable); > >> > >> - this.message = message.toString(); > >> + StringBuffer buffer = new StringBuffer(); > >> + buffer.append(message.toString()); > >> + if (throwable != null) { > >> + buffer.append(" Caused by :"); > >> + buffer.append(throwable.getMessage()); > >> + } > >> + this.message = buffer.toString(); > >> > >> code = FAULT_CODE_SERVER; > >> > >> } -- Daniel Kulp dkulp@apache.org http://dankulp.com/blog Talend - http://www.talend.com