Blog

Filter posts by Category Or Tag of the Blog section!

Asp.net: Don't do that, do this!

Friday, 28 February 2014

This blog post is about what I learned from the presentation by @DamianEdwards on here. As it was so interesting so I decided to write a blog post about that. It seems that Most of the points are about using Asp.net web form techniques.

 

Standard compliance

Control Adapters: Try to Avoid control adapters in asp.net web form as they are originally designed to support mobile devices. instead, try to use standard HTML and CSS and mobile-specific design if you want to make it responsive. And also Try to Avoid using style properties in asp.net web form in code behind, instead try to use CSS style sheets as they are maintainable in CSS classes.

Page and control callbacks: try to avoid using page callback or any control with the callback in asp.net web form and try to use Ajax, Web API, SignalR, MVC actions instead.

Capability detection: Try to avoid BrowserCaps feature in asp.net and use client-side detection such as modernizer to determine the capability of the browser.

 

 

Security

Request validation: Try to use @foo (in MVC razor) and <%foo %>(in web form) and JavaScriptStringEncode and overall client checks to protect your site against XSS attacks.(although in my opinion It's better to have server-side check for more security but client-side checks are required to reduce the requests for server)

Cookies and Session authentication: Do not use cookies and session authentication because it's not safe for hijacking attacks. Instead, use require cookies and SSL cookies.

EnableViewStateMac: Do not make EnableViewStateMac as false because it will provide the Cross Site Scripting attack.

Medium trust: If you are running two application in a server, don’t use medium trust and place untrusted applications into their own application pools and run each application pool under its own unique identity.

<appSettings>: Do not make <appSettings> as disable

UrlPathEncode: Don't use it to encode arbitrary user-provided strings, Use UrlEncode to encode meant to appear as a query string parameter in a URL.

 

Reliability and performance

PreSendRequestHeaders and PreSendRequestContent: Don't use these methods within IHttpModule instances and use native IIS modules instead.

Asynchronous page events: Try to avoid async void methods for page lifecycle events. (for example Page_Load in web form) and try to use Page.RegisterAsyncTask() instead.

Fire-and-forget work: Don't use Timers and ThreadPool from asp.net and try to move them to a windows service(you can use WebBackgrounder to do that)

The request entity body: Try to not to use Request.Form and InputString before the HandlerExecute event. instead, you Can use Request.GetBufferlessinputStream() and GetBufferedInputStream()

Response.Redirect & end: By default Response.Redirect(string) calls Response.End(), which abort the current thread in the asynchronous request. but for asynchronous handlers, Response.End() does not abort the current thread. so try to avoid using Response.Redirect

EnableViewState & ViewStateMode: Try to avoid using EnableViewState, instead you can set ViewStateMode as "Disabled" and "Enabled" instead

SqlMembershipProvider: Use UniveralProviders instead of sqlMembershipProvider to work with all databases that entity framework supports. (it's available in NuGet package manager)

Long-Running request: Try to avoid asp.net session as asp.net release the session object lock. Instead, Try to use WebSocket or signalR for long-running requests if you can.

 

For more detail about the exact reason for the above quotes, you can see the presentation. 

Category: Software

Tags: Asp.Net

comments powered by Disqus