Q&A: ASP.NET Master Page - <script> tag path issue fix

Today a colleague of mine asked me if I knew how to fix his JavaScript include problem. While I used to know the answer in the amount of time it took me to try and recall it he had found it on his own. What can I say, he is a smart guy.

Regardless, here is that solution for everyone's reference:

The Problem

Lets say you have a situation where you have a master page with many other pages in various places such as the root path and sub-folders using it.

Now lets also add that this mater page has a reference to a common script include such as a JavaScript .JS file. The problem you will then run into is that just having this code wont find the common.js file once you go one level or more deep into your sub-folders

Broken Code:
<script language="javascript" type="text/javascript" src="/Common.js"></script>

Instead you need something that will dynamically change the path of the script no matter where you go, and this is the solution:

Solution:
<script language="javascript" type="text/javascript" src="<% =ResolveUrl("~/Common.js") %>"></script>

This is not the only solution

There is more then one way to fry a potato (or something like that) but this is one approach that works. If you have other solutions please feel free to respond to this thread and post them.

Upgrading ASP.NET 1.1 Applications to 2.0

Someone recently asked me if I had any documentation with guidance on upgrading ASP.NET 1.1 applications to 2.0. Luckily Microsoft has put together a very descent public guide for just such a question and here is the link:

http://msdn.microsoft.com/en-us/asp.net/aa336650.aspx

This Upgrading from ASP.NET 1.x guide has many good links but those that stand out to me as essential starting points include:

• Common ASP.NET 2.0 Conversion Issues and Solutions – Technical Article
• Step-By-Step Guide to Converting Web Projects from Visual Studio .NET 2002/2003 to Visual Studio 2005 – Technical Article
• Update to the Web Project Conversion Wizard – Download

for those coming from ASP classic there is even a guide for that assuming you are going to ASP.NET 2.0. This guide is titled Migrating from ASP to ASP.NET 2.0 though I would never recommend an “upgrade” for such a transition but instead a total rewrite of the legacy application.

Benefits of Moving to ASP.NET 2.0

To me a big question in all of this is why would you even be upgrading an application in such a direction. Clearly ASP.NET 1.1 is supported by IIS 6.0 so deployment even in Windows 2003 should not be an issue and im going to make the wide assumption that most applications in ASP.NET 1.1 tend to be older software that is only maintained lightly (at least from my experiences). In such a case going through an upgrade can be more pain then its worth. Instead a rewrite of the next version to ASP.NET 3.5 would be a more sensible solution and take better advantages of all the latest technologies, including the extremely powerful IDE we call Visual Studio 2008.

Clearly for very large systems though that may not be an option and in those case I can see the value in trying to save the business logic or other layers by using this approach. There is no one answer for this, its just a decision that must be made.

On another point having worked with VS 2003 for a small project recently I can definitely say I miss even VS 2005 and its “powerful features” such as debugging visualizers or other richer IDE features. Getting these advantages might in some cases be worth an upgrade in itself.

Reminder

And just to be clear, everyone does remember that in Visual Studio 2008 you can open and work with ASP.NET 2.0 project seamlessly, right? Okay just making sure.

(If this is news to you, check out Scott Gu’s post on the subject titled: VS 2008 Multi-Targeting Support)

An Additional Resource

Searching the Internet you will definitely find additional places with guidance for such an upgrade, but one place that stands out for me is a blog post by my colleague Peter Laudati. His posted titled .NET 1.1 to .NET 2.0 Migration is an even richer collection of resource son this topic, so be sure to check it out.

Update: Peter emailed me to point out that another great post exists on this topic by our common colleague Daniel Moth. Its an excellent posting and has some unique points so definitely check it out: Migrating from .NET Framework v1.x to Visual Studio 2008

MVC Preview 3 Released

Scott Guthrie just announced that ASP.NET MVC Preview Release 3 has been released to the public. Here is a summary of the changes at a high level:

Controller Action Method Changes

Improved HTML Helper Methods

URL Routing Improvements

Richer URL Route Mapping Features

For complete details see ScottGu’s post about this release.

CodePlex Source Code

Its also worth noting that the MVC patterns source code is made available on CodePlex in case you are really feeling adventures.

Visual Studio 2008: Title Tag in MasterPage

Today I figured out an annoying problem and want to share the resolution with you. This is not a bug, its just a behavior if not realized quickly can cause minutes (or worse) of frustration.

Problem - Title Tag being overwritten with "Untitled Page"

I created a master page for my ASP.NET 3.5 powered Website using Visual Studio 2008. I set the <title>My Title</title> in the head as normal.

I then built multiple Web Content Forms that held my actual content for the various pages. (Web Content Forms is basically a page that uses the Master Page as the root style definition, I really don't like the name they used, but that's not my decision LOL)

Everything was working fine until I noticed my title in Internet Explorer during testing which said "Untitled Page". This couldn't be, I was sure I had set the Title to a different value.

Looking in the Master Page sure enough the <title> tag existed and looked valid. This didn't make sense.

I then looked into the new ContentPlaceHolder for the HEAD (which is a new feature of VS 2008), since I thought perhaps something in there on my individual pages was overwriting the masterpage definition of the Title, again no luck.

Solution

After a few more minutes I had realized my stupidity, the individual pages page element at the top (<%@ Page) has an attribute called Title, and it was set to: Title="Untitled Page"

Mystery solved, this was overwriting my masterpage definition. Removing this attribute all-together from the underlying pages fixed the issue.

This was something really stupid and I hope this post saves someone a few minutes of their life.

Let Users Upload Files: A Security Hole

Scott Mitchell wrote an interesting blog post called Another Potential Gotcha When Creating a Website that Allows Users to Share Uploaded Files. This post talks about a security concept that should be almost obvious but yet I must admit, I never thought of it in this way.

While you should read the article for yourself let me summarize the important part: If you let your users upload files and then download them via a URL they can upload script that executes on your server.

Scott posts a solution of turning Execute Permissions for scripts to None. Check out his full article and improve your security profile!

Security Analysis

Overview

Building applications that are exposed directly to the Internet presents many challenges to engineers especially those working in smaller and less mature development shops. Security tends to be one of these challenges and in my opinion is one of the hardest to approach correctly.

Two years ago in 2005 I found myself architecting and building an ASP.NET 2.0 application from the ground-up. This particular project would expose sensitive personal information to the Internet directly for the first time in my company’s history and we had no experience on keeping it secure. (Citrix was used for all previous projects which added the extra security wrapper). A flawed design had the potential to hurt thousands of people so I took this topic very seriously.

My security analysis started on a long flight from the United States to the Ukraine for a family visit (what better way to pass the time of a long flight then geek out on security?). To begin my analysis I started to piece together the various aspects of the system that needed security considerations and soon realized I was struggling on creating what I would consider a complete list.

The root of my problem was I neither had a solid reference-base to start with, nor a large amount of experience in security. To try and overcome these limitations I immediately began to piece together every major system or concept my application would interact with and had security considerations. Four hours later this warped into the Security Zones Diagram featured above. This simple diagram breaks up the various part of the system that needed my attention in any security analysis phase of an ASP.NET application.

(Click on the above diagram to see high-resolution version)

Zones and Examples Breakdown

• Personnel (People Factor)
  Example: Have we made an effort to train our end-users not to respond to emails requesting their password?
• PC (End-user computers)
  Example: Have we considered what impact key-logging Trojans might have on our security?
• Internet (External Network Traffic)
  Example: Have we made an effort to security all traffic from our application as it crosses the Internet?
• Firewall
  Example: Have we considered all the ways a firewall can help block our application from harm such as limiting sensitive resources access to specific restricted IP ranges?
• Load Balancer
  Example: Have we considered all the ways a load balancer can help block our application from harm such as real-time layer-7 traffic analysis?
• IIS Servers (Web and App) Configuration
  Example: Have we locked down our IIS server to only expose the type of physical files required to run our application and not sensitive resources such as code assemblies?
• Your ASP.NET hosted code
  Example: Have we made sure our custom authentication code locks out users when a dictionary attack is suspected?
• .NET Framework
  Example: Have we made sure to service-pack the .NET framework with all the latest security hot-fixes?
• SQL Servers Configuration
  Example: Have we configured our SQL servers in a secure way that restricted which resources can talk to it directly?
• SQL Server Code (Users, T-SQL code, etc)
  Example: Have we limited our user’s access to the minimum rights such as Stored Procedure execution rights in only a specific database?
• SSL Tunnel
  Example: Have we made sure that all sensitive information is transferred using SSL when it leaves our network?
• Network Data (Internal)
  Example: Have we setup VLAN’s and Routers to segment off our internal sensitive traffic away from the general network where it could potentially be intercepted?
• Email Communication
  Example: Have we made sure no services send sensitive information in clear-text emails?

Documenting and Analyzing

Once you consider all the various aspects that could potentially impact your application you will quickly realize that the list can grow to such a size that it can almost feel unmanageable. This is something that must be avoided if you are to have a constructive analysis process that leads to actual actions. Here is my recommended approach for managing this:

• Get all the key player(s) thinking about the Security Zones or some other common method of highlighting all the key areas. (and do this early on in the process)
• Time-box this exercise and demand feedback if possible. Otherwise you’ll never get input, people are busy after all.
• Use SharePoint lists, Google Shared Documents or any list that can be easily viewed and updated by multiple people with minimum conflict. Making it easy for people to contribute and keeping the process transparent is essential
• Setup a meeting for a group review of the documented risks. Rate the risks into three categories: Priority, Next Phase or Won’t Fix. Priority items should be added to the development or networking tasks for your current project phase as critical-path items. These items cannot be seen as external to the key deliverables of the project
• Next Phase items should be added to your next-phase project plan and treated as priority critical-path items during that phase
• Won’t Fix items should remain documented but be considered irrelevant or so unlikely that investing time into resolving them would not be constructive
• Keep this process alive through the entire development cycle of your application since as the application evolves it will constantly bring new security challenges or considerations to the table

Conclusion

Having any process is better then having no process and while I will not claim to be a security expert the above has at least provided me a context from which I can analyze security risk.

Please feel free to use any part of my recommendations or even the diagram itself if it helps you.

Please Comment

Know of a better way? Have criticism of my approach? Have general feedback? Please post your comments, I really look forward to it.