Programming Microsoft ASP.NET 4 - Dino Esposito [405]
public abstract Object Get(String key);
public abstract void Remove(String key);
public abstract void Set(String key, Object entry, DateTime utcExpiry);
In ASP.NET 4, the mechanism of output caching has been made open, but no additional providers are provided as part of the framework. At the following URL, however, you can find the source code of the AppFabric Caching Services output provider written by one of the Microsoft ASP.NET architects: http://aspnet.codeplex.com/releases/view/46576.
Summary
The ability to store in-memory chunks of frequently accessed data becomes a winning factor in the building of scalable Web applications that handle significant volumes of data. Caching, however, is a double-edged sword, and if it’s abused or misused, it can easily morph into an insidious weakness. This typically happens when the quantity of memory-held information grows uncontrolled and beyond a reasonable threshold. Aside from the performance repercussions, the theoretical possibility that the data stored in the cache can grow uncontrolled also opens up security concerns. A denial-of-service (DoS) attack, in fact, might succeed in flooding the Web server’s memory with useless data if the caching subsystem is not well designed.
Caching is mostly about memory. In the short run, you can perhaps even find that some good caching improves the overall performance enough to appease your customer or your boss. I’m not at all claiming that caching can fix design holes, but caching can sometimes put a patch on suboptimal performance and buy you time to rethink and refactor the application properly.
To build high-performance applications, a fundamental guideline is “Cache as much as you can.” However, be aware that there’s a threshold you should never exceed. The more aggressive you are with caching, the more you should be concerned about the invisible memory threshold that suddenly turns good things into bad things.
In ASP.NET, caching comes in two complementary forms: page output caching and the application cache. The former is a relatively quick and simple approach to apply caching rules to a page including client, downstream, and server caches. The benefit is that a request can be served without spinning up the ASP.NET pipeline. Using page output caching doesn’t necessarily make your application faster, but it reduces the load on the server.
Application cache refers to a comprehensive caching API designed to let you place a caching layer inside your business or data tier. The application cache relies on the machine-specific Cache object as well as the distributed AppFabric Caching Services or analogous open-source or commercial products. Also, in this cache the primary goal is to reduce the load on databases and services, minimizing roundtrips and increasing scalability. No serious Web application today can do without a good layer of caching—at all possible levels.
Chapter 19. ASP.NET Security
Beware of the man who won’t be bothered with details.
—William Feather
By nature, Web applications are subject to several types of attacks whose damage and impact can vary quite a bit, depending on the characteristics of the application itself. The most secure Web application is the application that actually resists attacks, not the application just designed to. Security is a rather intricate puzzle whose solution varies from one application to another. The important thing to remember is that, more often than not, security is manifested through a successful mix of application-level and system-level measures.
Many developers have learned on their own that security is not a feature that can be easily added to existing applications or introduced late in the development stage. Security is inherently tied to the functions of an application and should be planned as one of the first features, very early at the design level. For example, isolating modules of the application particularly sensitive to security would greatly simplify using stricter security measures without