Skip to main content

Posts

Showing posts from December, 2010

Asp.Net 4.0: An Overview-Part-II

This post is in continuation with the series started in my earlier post and continues to explore the remaining features as described in the post. Let’s start by considering the point 2 in the earlier post i.e. Shrinking Session State Shrinking Session State  ASP.NET (3.5) provides two default options for storing session state across a Web farm: a session-state provider that invokes an out-of-process session-state server, and a session-state provider that stores data in a Microsoft SQL Server database.session state has to be serialized before it is sent to remote as both options involve storing state information outside a Web application's worker process the size of the serialized data can grow quite large as more data is added to the session state. ASP.NET 4 introduces a new compression option( compressionEnabled ) .When this configuration option is set to true, ASP.NET will compress (and decompress) serialized session state by using the .NET Framework System.IO.Compression.GZipStr

Asp.Net 4.0: An Overview-Part-I

Asp.net 4.0 introduces a lot of new features and controls that can be broadly categorized as depicted below. 1. Server Side enhancements 2. New Controls 3. ASP.Net MVC enhancements 4. Dynamic Data This post covers only the First part i.e. Server Side enhancements. Server Side Enhancements A) Caching Enhancements B) Shrinking Session State C) Performance Monitoring Improvements  D) Shrinking Web.config E) Shrinking session state F) View state on individual controls   Caching Enhancements Prior to Asp.net 4.0, page output is stored in memory in a private area of the ASP.NET cache. If the Caching is done for large number of pages, the output cache puts additional pressure on the web server by consuming memory and generating frequent updates to the cache object. ASP.NET 4.0 introduces new concept of  storing page responses outside the ASP.NET worker process. The new Cache API enables the usage of any of the storages that includes storing cache data in disk, storing cache data using custom

URL Encryption/URL Rewriting

One of the main security checks that the most of the sites implement is URL encryption. URL encryption in simple terms converts the human readable address into encrypted format. Most of the times only a part of the URL is encrypted that makes it secure by hiding I the inner implementation details used on the page. Consider an example: Imagine a page which provides user details and let’s assume that the URL for that is http://[site]/users?user_id=[userid]. The same page is called over and again, just y differing the user_id parameter. The simplest approach is to encrypt this value so that it becomes hard to guess the user_id and prevent unauthorized access. (Assuming that Role-based security is not used, as provided in ASP.Net). This looks simple; however one of the side-effects arising out of this could be JavaScript or any code that reads the value from Querysting. To avoid this issue we need to encrypt the page when it is rendered and decrypt the values when there is a need. Easier s