Archive

Archive for the ‘ASP.NET’ Category

IQueryable vs. IEnumerable

October 4, 2014 Leave a comment

What is the difference between returning IQueryable<T> vs IEnumerable<T>?

IQueryable<Customer> custs = from c in db.Customers
where c.City == "<City>"
select c;

IEnumerable<Customer> custs = from c in db.Customers
where c.City == "<City>"
select c;

Will both be deferred execution and when should one be preferred over the other?   Yes, both will give you deferred execution. The difference is that IQueryable<T> is the interface that allows LINQ-to-SQL (LINQ.-to-anything really) to work. So if you further refine your query on an IQueryable<T>, that query will be executed in the database, if possible. For the IEnumerable<T> case, it will be LINQ-to-object, meaning that all objects matching the original query will have to be loaded into memory from the database. In code:

IQueryable<Customer> custs = ...;
// Later on...
var goldCustomers = custs.Where(c => c.IsGold);

That code will execute SQL to only select gold customers. The following code, on the other hand, will execute the original query in the database, then filtering out the non-gold customers in the memory:

IEnumerable<Customer> custs = ...;
// Later on...
var goldCustomers = custs.Where(c => c.IsGold);

This is quite an important difference, and working on IQueryable<T> can in many cases save you from returning too many rows from the database. Another prime example is doing paging: If you use Take and Skip on IQueryable, you will only get the number of rows requested; doing that on an IEnumerable<T> will cause all of your rows to be loaded in memory.

Original Post

Advertisements

Forcing Your Site to Use SSL with just the web.config

November 26, 2013 Leave a comment

I stumbled across a great way to force your ASP.Net site to redirect and force the site to use SSL.

Capture

passiveftp

Categories: Architecture, ASP.NET, IIS

IIS7 ‘classic’ vs. ‘integrated’ pipeline mode

September 30, 2013 Leave a comment

Classic Mode (the only mode in IIS6 and below) is a mode where IIS only works with ISAPI extensions and ISAPI filters directly. In fact, in this mode, ASP.NET is just an ISAPI extension (aspnet_isapi.dll) and an ISAPI filter (aspnet_filter.dll). IIS just treats ASP.NET as an external plugin implemented in ISAPI and works with it like a black box (and only when it’s needs to give out the request to ASP.NET). In this mode, ASP.NET is not much different from PHP or other technologies for IIS.

Integrated Mode, on the other hand, is a new mode in IIS7 where IIS pipeline is tightly integrated (i.e. is just the same) as ASP.NET request pipeline. ASP.NET can see every request it wants to and manipulate things along the way. ASP.NET is no longer treated as an external plugin. It’s completely blended and integrated in IIS. In this mode, ASP.NET HttpModules basically have nearly as much power as an ISAPI filter would have had and ASP.NET HttpHandlers can have nearly equivalent capability as an ISAPI extension could have. In this mode, ASP.NET is basically a part of IIS.

Categories: ASP.NET, General, HTTP, IIS

Entity Framework: Self-Tracking Entities

December 6, 2011 Leave a comment

Working with Self-Tracking Entities

In an Entity Framework application, an object context is responsible for tracking changes in the entities in an object graph. However, in N-tier scenarios, the object context might not be available on the tier that modifies the entities. Starting with the .NET Framework version 4, self-tracking entities can help you track changes in any tier.

NOTE: Use self-tracking entities only if the object context is not available on a tier where the changes to the object graph are made. If the object context is available, use EntityObject derived types, or “plain-old” CLR objects (POCO) types, or POCO proxy types.

Starting with Microsoft Visual Studio 2010, the ADO.NET Self-Tracking Entity Generator template generates self-tracking entities. This template item generates two .tt (text template) files: .tt and .Context.tt. The .tt file generates the entity types and a helper class that contains the change-tracking logic that is used by self-tracking entities and the extension methods that allow setting state on self-tracking entities. The .Context.tt file generates a typed ObjectContext and an extension class that contains ApplyChanges methods for the ObjectContext and ObjectSet classes. These methods examine the change-tracking information that is contained in the graph of self-tracking entities to infer the set of operations that must be performed to save the changes in the database.

Read more…

New Syntax for HTML Encoding Output in ASP.NET 4

August 19, 2011 Leave a comment

Thanks to Scott Guthrie…

Today’s post covers a small, but very useful, new syntax feature being introduced with ASP.NET 4 – which is the ability to automatically HTML encode output within code nuggets.  This helps protect your applications and sites against cross-site script injection (XSS) and HTML injection attacks, and enables you to do so using a nice concise syntax.

HTML Encoding

Cross-site script injection (XSS) and HTML encoding attacks are two of the most common security issues that plague web-sites and applications.  They occur when hackers find a way to inject client-side script or HTML markup into web-pages that are then viewed by other visitors to a site.  This can be used to both vandalize a site, as well as enable hackers to run client-script code that steals cookie data and/or exploits a user’s identity on a site to do bad things.

One way to help mitigate against cross-site scripting attacks is to make sure that rendered output is HTML encoded within a page.  This helps ensures that any content that might have been input/modified by an end-user cannot be output back onto a page containing tags like <script> or <img> elements.

 

Read more…

Categories: ASP.NET, Encoding, Security Tags:

Web Application Security Vulnerabilities

Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention.

Sometimes, these paths are trivial to find and exploit and sometimes they are extremely difficult. Similarly, the harm that is caused may range from nothing, all the way through putting you out of business. To determine the risk to your organization, you can evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to your organization.

Together, these factors determine the overall risk.

The new OWASP Top Ten can be seen below:

Read more…

Preventing Cross-site scripting attacks using Microsoft Anti-Cross Site Scripting Library

February 16, 2011 Leave a comment

Cross site scripting is one of the biggest threats in web applications. I would like to cover how to prevent Cross-site scripting attacks using Microsoft Anti-Cross Site Scripting Library.

What is Cross-Site scripting(XSS)?

A website is said to be vulnerable for XSS if proper validation/encoding of input is not done before using/rendering the output. For example, you are taking input from a textbox and without validation/encoding you are embedding in response data(as below).

using System;
public partial class _Default : System.Web.UI.Page
{
protected void Button1_Click(object sender, EventArgs e)
{
String Input = TextBox1.Text;

//XSS
Response.Write(Input);
}
}

 

Read more…

%d bloggers like this: