MVC http request flow

This is a good diagram that shows how a http request flow work in the MVC framwork.

Request Flow

In regular ASP.NET web form applications, URLs are usually mapped to physical disk files. When a URL is requested, the code of the associated file gets executed, which generates the HTML. However, in the ASP.NET MVC Framework the URLs are tied with the Controllers rather than the disk file. The component that is responsible to map the URL with the Controller is the Routing Handler. When the application starts, it is required to register the URL Routing Rules, which the Routing Handler uses to map the controller when the request arrives. Let's take a quick view of how a request is carried in different layers of the ASP.NET MVC Framework:

Figure 2: The Request Flow

• The user requests a URL.
• The ASP.NET MVC Framework evaluates the requested URL against the registered Routing Rules and finds a matching Controller. The Framework forwards the request to the matching Controller.
• The Controller calls the Model to build ViewData. It can call the model multiple times depending upon the ViewData that it is building.
• The Model, as mentioned earlier, is the middle tier, which might involve data access components, workflow activities, external web service dependencies etc. The Model returns the requested data to Controller.
• The Controller selects a View and passes the data to the View which it previously got from the Model. The View Renders the data and returns the generated HTML to the User.

How to tell if you have SSIS installled on SQL 2005

Open SQL Server Configuration Manager and on the SQL Server 2005 Services
section look for SQL Server Integration Services.

To install you need to check the Integration Services box when you run the
SQL Server setup program.

Cross site scripting and ways to code against it

Cross site scripting is a vulnerability that exists when the software does not sufficiently validate, filter, escape, and encode user-controllable input before it is placed in output that is used as a web page that is served to other users.
Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications. It's pretty much inevitable when you combine the stateless nature of HTTP, the mixture of data and script in HTML, lots of data passing between web sites, diverse encoding schemes, and feature-rich web browsers. If you're not careful, attackers can inject Javascript or other browser-executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you (because, after all, it *did* come from you). Suddenly, your web site is serving code that you didn't write. The attacker can use a variety of techniques to get the input directly into your server, or use an unwitting victim as the middle man in a technical version of the "why do you keep hitting yourself?" game. http://cwe.mitre.org/top25/#CWE-79

Some references to help protect against XSS vulnerability
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API 
http://msdn.microsoft.com/en-us/library/aa973813.aspx

In short- Validate your input and encode your output.