Well, I'm back... they finally coughed up the ransom! Truthfully, I've been busy and have wanted to put this particular post together for some time. Since It's still a work in progress, I decided to divide it up into a series. That way I can't procrastinate any further! I have limited experience with SharePoint development in general. I have never created a custom CAS policy and I am using the 1.3 version of the VS extensions for the first time, so it should be interesting.

VSeWSS 1.3


Many developers are overwhelmed by the plethora of tools out there right now for creating and deploying simple components in SharePoint. My personal favorite so far has been STSDEV although I had some problems with the most recent version. At the end of the day, I decided to either hand-roll my Web Parts and deploy with STSADM, or use the Visual Studio Extensions. The reason a lot of people have used tools other than VSeWSS is because the the extensions have been considered pretty limited up to now. But that seems to be changing and version 1.3 has some really cool features.

VSeWSS 1.3


You can download the extensions, both 32 bit and 64 bit, as well as the pre-release notes. Uninstall version 1.2 first, if you already have it installed.

We're going to take the new 1.3 CTP of Visual Studio Extensions for VS 2008 for a test drive. We will create a custom Web Part which will display some data from an XML file. We will deploy our Web Part to the bin folder rather than than to the Global Assembly Cache (GAC); deploying to the GAC involves resetting IIS which is impractical if you have a production environment with a single Web Front End (WFE) server. In order to run this code from the bin folder, we will create a custom code access security (CAS) policy.

VSeWSS 1.3


When you opt to create a new Web Part project, you will be presented with the New Project dialog box. Opt to deploy to the bin folder. Your Solution Explorer window and WSP View should now resemble those in the diagrams shown.

VSeWSS 1.3


In the next part, we'll take a look at the architecture of Features in general; the aim is to keep this as simple as possible and get something up and running. The most common problems people are having are security-related. We will look at this more closely and set out the steps necessary to enable your code to run in a secure environment. In the meantime, you can study up on the use of Features.

ASP.NET Data Input Validation

by admin 1. November 2008 18:18

Data Input I'm no security expert, and as such, I think I'm a member of an ever-growing group of Web developers who fly by the seat of their pants when it comes to the security of their Web forms. As an ASP.NET developer I have had a tendency to presume that the framework is going to insulate me from most of the "nuts and bolts stuff". Of course this is not the kind of beneficial abstraction that frameworks were meant to provide us with. It is up to each of us to take responsibility for the code we create. Testing, even when it is carried out, shouldn't stop as soon as we find out that our code "is working". There needs to be some baseline better practise for creating everyday Web forms other than relying on ValidateRequest being set to true.

Recently I published a post entitled 500,000 SQL Injection Attacks. The half a million attacks actually occurred in a single week. This is mind boggling. A lot of the attacks targeted older ASP sites and I was surprised at how much of this old code was still out there. What surprised me most was how many idiots were out there calling themselves developers, not to mention the bottom-line execs who hired them in the first place. That 500,000 sites were attacked in a single week should be telling us something. We need more qualified programmers in the industry and we need the education system to introduce students to the World of IT that they are going to be living in.

Most security holes are created by developers with little understanding of security issues. These security holes are then exploited by hackers who understand these security issues only too well. It's a lethal recipe. Developers need to understand what it is they have to protect against and how to go about doing it. The tools and guidance for creating safer Web forms are available to us right now if we know where to look.

From a security point of view, our Web forms are naked and 100% vulnerable. We need to look at all the ways data is passed to them and test as appropriate:

    * Form Fields
    * URL Query Strings
    * Cookies
    * Database
    * ViewState

The most prevalent forms of attack seem to be Script Injection, Cross Site Scripting and SQL Injection. As for SQL Injection, this can be mitigated against by using parameterized queries. It is the act of parameterizing the database queries that make stored procedures so resilient to attack. The other forms of script attack can be handled by downloading and using the Microsoft Anti-Cross Site Scripting Library in your Web application projects.

A best practise would consist of the use of this library in conjunction with proper data validation (validators) and filtering (regular expressions). If you have existing code which you know is vulnerable you can still use tools to inspect your code and then you can implement the necessary protection measures where needed.

On the MSDN Code Gallery, there is a complete ASP.NET 2.0 Reference Security Implementation which you can download and explore. It was created in VS 2005 and includes an installer. This is a very helpful resource to answer any questions you may have. Note: you must have VS 2005 installed for this to work.

I've saved the best news for last :-) The Microsoft CIGS (Connected Information Security Group) are working on the new Security Runtime Engine. It is a HTTP module which will provide protection against the most common Web application security vulnerabilities, including Cross Site Scripting. The CIGS group are currently testing it and the beta should be available shortly.

ASP.NET Email Strategy Pattern

by admin 22. September 2008 18:46

Email Sometimes when building websites, we need to generate email more than once. For example a site could have a contact form and a user-filled form, both generating email to the site owner. You don't need to be able to spout the name of every software pattern verbatim, to recognize the duplication here and the need to somehow factor it out.

We typically use the strategy pattern where we might have several different implementations of something and want to abstract out the common functionality. The strategy is also known as the provider pattern and I prefer this term. An interface is a good candidate data structure to use here because we can stipulate that a client class must implement a mailing method, and we can leave the details to that class. Let's look at some code...

Typical Scenario

Here are some typical Web.config email settings and code to send an email:

    <add key="ToEmailAddr" value="info@mysite.com" />
    <add key="FromEmailAddr" value="info@mysite.com" />

        <smtp from="info@mysite.com">
            <network host="smtp.mymailserver.net" port="25" />


using System.Configuration;
using System.Net.Mail;
using System.Web.Configuration;

System.Configuration.Configuration config
  = WebConfigurationManager.OpenWebConfiguration(base.Request.ApplicationPath);
AppSettingsSection appSettings = (AppSettingsSection)config.GetSection("appSettings");

string toAddress = appSettings.Settings["ToEmailAddr"].Value;
string fromAddress = appSettings.Settings["FromEmailAddr"].Value;

SmtpClient smtpClient = new SmtpClient();

MailMessage message = new MailMessage();
message.IsBodyHtml = false
message.Priority = MailPriority.High;
message.DeliveryNotificationOptions = DeliveryNotificationOptions.OnFailure;

    message.Subject = "Subject: " + this.subjectBox.Text;
    message.Body = "Sender: " + nameBox.Text.Trim() + "\n";
    message.Body += "Street: " + streetBox.Text.Trim() + "\n";
    message.Body += "City: " + cityBox.Text.Trim() + "\n";
    message.Body += "State: " + stateDropDown.SelectedValue
        + " " + zipBox.Text.Trim() + "\n";
    message.Body += "Email: " + emailBox.Text.Trim() + "\n";
    message.Body += "\n\n" + this.messageBox.Text + "\n\n";

    smtpClient.Send(fromAddress, toAddress, message.Subject, message.Body);
catch (Exception ex)
    // Log error


Strategy Pattern

While this particular email example will not save us a whole lot of typing, it does enable us to implement the email functionality differently for each client class that uses it. This may be useful if we had to send mail through several different servers; in such a case we might also want to configure our settings in code, or factor out our Web.config sections. Factoring out parts of your Web.config is another topic and can be used to greatly simplify deployment.

interface IGenerateMail
    // Classes using this interface must implement this method
    void SendMail(string to, string from, string subject, string body);


// Implementing the Strategy Pattern
public class RealtySMTPMailer : IGenerateMail
    //(string from, string to, string subject, string message)
    public void SendMail(string from, string to, string subject, string message)
        MailMessage realtyMessage = new MailMessage(from, to, subject, message);
        SmtpClient smtpClient = new SmtpClient();

        realtyMessage.IsBodyHtml = false;
        realtyMessage.Priority = MailPriority.High;
        realtyMessage.DeliveryNotificationOptions = DeliveryNotificationOptions.OnFailure;

        smtpClient.Send(from, to, subject, message);


// Snippets from revised contact form
private RealtySMTPMailer mailProvider;

public Contact()
    mailProvider = new RealtySMTPMailer();

public Contact(RealtySMTPMailer mailProvider)
    this.mailProvider = mailProvider;

// Send button event handler
System.Configuration.Configuration config
  = WebConfigurationManager.OpenWebConfiguration(base.Request.ApplicationPath);
AppSettingsSection appSettings = (AppSettingsSection)config.GetSection("appSettings");

string toAddress = appSettings.Settings["ToEmailAddr"].Value;
string fromAddress = appSettings.Settings["FromEmailAddr"].Value;

StringBuilder mailBody = new StringBuilder();

mailBody.Append("From:" + " " + nameBox.Text.Trim() + "\n");
mailBody.Append("Address:" + " "
    + streetBox.Text.Trim() + ", "
    + cityBox.Text.Trim() + ", "
    + stateDropDown.SelectedValue + " "
    + zipBox.Text.Trim() + "." + "\n");
mailBody.Append("Email:" + " " + fromAddress + "\n\n");    
mailBody.Append("Message:" + "\n" + messageBox.Text.Trim());

mailProvider.SendMail(fromAddress, toAddress, subjectBox.Text.Trim(), mailBody.ToString());


We can now implement email functionality anywhere in the site and change that implementation without breaking code elsewhere. You might notice some refactoring going on in the last snippet; I substituted a string builder to construct the email, as it is more efficient. Remember, when refactoring you must resist the temptation to re-code the logic.

ASP.NET Email Resources

Sending Email with System.Net.Mail - Scott Guthrie

Sending Email in a Development Environment without an SMTP Server

Sending Email from ASP.NET using your Gmail Account