You read it right. There is a very cheap way to shield exception information from an ASP.NET web service. Mind you, this is available only from ASP.NET 2.0 (and upwards presumably).
So, what is exception shielding for web services? Preventing potentially valuable exception information from leaking to the calling client. It’s a good security practice to shield unhandled exceptions that occurred inside your web service from bubbling up to the ASP.NET HttpHandler for ASMX. Take this web service:
[WebService(Namespace = “http://tempuri.org/”)]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ToolboxItem(false)]
public class FaultyTowers : System.Web.Services.WebService
{
[WebMethod]
public string HelloFawlty()
{
throw new ArgumentException(“Stop right there, Basil!”);
return “No way, Manuel”;
}
}
The handler will take over and return a SOAP fault to the client. The <soap:Fault> element will contain (wrapped inside a SoapException) the type and message of the exception that occurred, plus a stacktrace and references to the file location of the source file. It will look like this:
<?xml version=“1.0“ encoding=“utf-16“?>
<soap:Envelope xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/“ xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance“ xmlns:xsd=“http://www.w3.org/2001/XMLSchema“>
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>
System.Web.Services.Protocols.SoapException: Server was unable to process request. —> System.ArgumentException: Stop right there, Basil!
at WebApplication1.FaultyTowers.HelloFawlty() in C:tempWebApplication1FaultyTowers.asmx.cs:line 23
— End of inner exception stack trace —
</faultstring>
<detail />
</soap:Fault>
</soap:Body>
</soap:Envelope>
You could jump through hoops to catch all unhandled exceptions that occur inside of your methods and throw your own SoapExceptions (in which case the exception isn’t altered). There is some guidance right here from the Patterns and Practices team.
Or you could set a new ASP.NET 2.0 diagnostics option in your web.config and let the ASP.NET runtime take care of not returning too much exception information.
<?xml version=“1.0“?>
<configuration>
<system.web>
<webServices>
<diagnostics suppressReturningExceptions=“true“ />
</webServices>
Setting the suppressReturningExceptions attribute to true (the default is false) will result in no information being included in the returned SoapException. The <soap:Fault> will now contain the following:
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>System.Web.Services.Protocols.SoapException: An error occurred on the server.</faultstring>
<detail />
</soap:Fault>
I say: recommended for production environments.
For a full-blown and more robust implementation, check the Web Service Software Factory from P&P and read an intro by Eric here.
