MSDN Magazine - October 2007 - (Page 46)

By default,AJAX service methods are invoked only using the POST verb and return JSON formatted data. However, by using the optional ScriptMethod attribute on individual service methods, you can change these settings. Figure 3 details the parameters supported by the ScriptMethod attribute. The data returned to the client can be changed to XML and you can even add support for GET requests. But as I mentioned, this apparently innocent change may open up new possibilities for attackers and expose the potential for cross-site calls to the method. The following code snippet shows the definition of a Web service method: [WebMethod] [ScriptMethod] public DateTime GetTime() { } If you’re not going to change any default settings (which is what I recommend for most cases), then the ScriptMethod attribute can be omitted. The WebMethod attribute is mandatory, though. Figure 2 Page Referencing a Non-Scriptable Service ASP.NET AJAX Services and SOAP Once created, an AJAX Web service is published as an ASMX resource. By default, it’s a public URL and can be consumed by AJAX clients, as well as discovered and consumed by SOAP clients and tools. But you can opt to disable SOAP clients and tools altogether. Just enter the following configuration settings to the web.config file of the ASP.NET application that hosts the service: The class may optionally inherit from the WebService class and must be decorated with the new ScriptService attribute: [ScriptService] public class TimeService : System.Web.Services.WebService { } Each script-callable method is declared public and tagged with the usual WebMethod attribute. Page methods are simply public, static methods—each marked as WebMethod—defined in the context of a single ASP.NET page. They can only be called from within the host page. Aside from storage differences, a call to a Web service or page method is processed in the same way by the ASP.NET AJAX environment. You have to understand that AJAX services represent a part of your back end. They’re not public Web services in the sense of a WS-* Web service, which are fully documented by a WSDL script and accessed via POST commands carrying SOAP data. AJAX services are really local services, usually defined in the same application that calls them. However, they can also be on a different Web app or even Web site, provided that they live in the same domain. The ScriptService attribute plays a key role by enabling the ASP.NET AJAX runtime to accept calls to the service. Without the ScriptService attribute, an exception is thrown on the server when you attempt to place calls. Figure 2 shows the message that is returned when an AJAX page links to service not flagged with the attribute. Note that the page shown in the figure is never displayed to any user. You do receive all that markup when you connect to an ASP.NET AJAX page that declares to use such a service. The markup returns an HTTP 500 error code because the internal ASP.NET machinery refuses to process script calls directed at ASP.NET Web services that lack the attribute. 46 msdnmagazine Cutting Edge This simple setting disables any protocols defined for ASP.NET 2.0 Web services (in particular, SOAP) and lets the service reply only to JSON requests. Note that with these settings on, you can no longer call the Web service through the browser’s address bar for a quick test. Likewise, you can’t ask for the WSDL adding the ?wsdl suffix to the URL. In order to enable ASP.NET AJAX in a Web application, you must include the following settings in the web.config file: The node drops the default HTTP handler for ASMX resources—the one handling requests via SOAP. The node adds a new HTTP handler that basically checks the content type of each incoming ASMX request and serves it via JSON if the content-type header is set to application/json. Otherwise, the HTTP handler assumes the request is SOAP-based and forwards the request to the standard ASP.NET 2.0 Web service handler. The request will be rejected if the SOAP protocol is disabled. In the end, and despite appearances, there is no SOAP neces-

Table of Contents Feed for the Digital Edition of MSDN Magazine - October 2007

Cover Contents Toolbox CLR Inside Out Basic Instincts Data Points Cutting Edge Pooled Threads WPF Threads Parallel Linq Parallel Performance Mobile Apps Test Run Foundations Windows with C++ Netting C++ .NET Matters { End Bracket } Net Nuptials

MSDN Magazine - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.