Programming Microsoft ASP.NET 4 - Dino Esposito [346]
Saving the Request to Disk
The SaveAs method lets you create a file to store the entire content of the HTTP request. Note that the storage medium can only be a disk file; no stream or writer can be used. Because ASP.NET by default isn’t granted write permissions, this method causes an access-denied exception unless you implement ad hoc measures. Granting the ASP.NET account full control over the file to be created (or over the whole folder) is one of the possible ways to successfully use the SaveAs method. The following listing shows possible content that SaveAs writes to disk:
GET /MyApp/Samples/Ch14/Misc/TestFilter.aspx HTTP/1.1
Connection: Keep-Alive
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: it,en-us;q=0.5
Cookie: .ASPXANONYMOUS=AGzHqyVAyAEkAAAAO ... MWE3YZreWoYt-jkSc_RwU169brWNTIw1
Host: localhost:1066
User-Agent: ...
UA-CPU: x86
If the intercepted request is a POST, you’ll find posted values at the bottom of the string.
Validating Client Input
A golden rule of Web security claims that all user input is evil and should always be filtered and sanitized before use. The @Page directive has an attribute—ValidateRequest—that automatically blocks postbacks that contain potentially dangerous data. This feature is not the silver bullet of Web input security, but it helps detect possible problems. From a general security perspective, you’re better off replacing the automatic input validation with a strong, application-specific validation layer.
The automatic input validation feature—ValidateRequest—is enabled by default and implemented via a call to the HttpRequest’s ValidationInput method. ValidateInput can be called by your code if the validation feature is not enabled. Request validation works by checking all input data against a hard-coded list of potentially dangerous data. The contents of the collections QueryString, Form, and Cookies are checked during request validation.
Summary
In this chapter, we covered some basic objects that are the foundation of ASP.NET programming: Server, Response, Request, and others. An ASP.NET application is represented by an instance of the HttpApplication class properly configured by the contents of the global.asax file. And both the HttpApplication class and the global.asax file found their space in this chapter too.
While discussing the interface of the objects that generate the context of an HTTP request, we reviewed in detail some specific programming issues, such as server-side page redirection and the setup of response filters. In the next chapter, we’ll discuss an important topic related to Web applications and ASP.NET—state management. Fundamentally, Web applications are stateless, but ASP.NET provides various mechanisms for maintaining application state and caching pages.
In ASP.NET 4, all intrinsic objects (except Cache) have been derived from a new base class to give developers better chances to be able to write testable Web pages.
Chapter 17. ASP.NET State Management
In the beginner’s mind there are many possibilities. In the expert’s mind there are few.
—Shunryu Suzuki
All real-world applications of any shape and form need to maintain their own state to serve users’ requests. ASP.NET applications are no exception. However, unlike other types of applications, they need special system-level tools to achieve the result. The reason for this peculiarity lies in the stateless nature of the underlying protocol that Web applications still rely upon. As long as HTTP remains the transportation protocol for the Web, all applications will run into the same problem—figuring out the most effective way to persist state information.
Application state is a sort of blank container that each application and programmer can fill with whatever piece of information makes sense to persist: from user preferences to global settings, from worker data to hit counters, from lookup tables to shopping carts. This extremely variegated mess of data can be organized and accessed according to a number of different usage