From the Washington Post, April 25, 2008:

Quote... Hundreds of thousands of Web sites - including several at the United Nations and in the U.K. government -- have been hacked recently and seeded with code that tries to exploit security flaws in Microsoft Windows to install malicious software on visitors' machines. Unquote...

Apparently there have been an estimated half-million attacks on different Web sites this week alone. There seems to have been a rush to judgement in trying to point the finger of blame at a recent Microsoft Security Advisory (951306). According to Bill Staples, Product Unit Manager for IIS, "Microsoft has investigated these reports and determined that the attacks are not related to the recent Microsoft Security Advisory (951306) or any known security issues related to IIS 6.0, ASP, ASP.Net or Microsoft SQL technologies."

These attacks are not related to said security advisory but are aimed at sites, on any platform, that are open to SQL Injection. What we are really seeing is a growth in SQL Injection over other types of attack. Although around for a long time now, this technique has been gaining in popularity among hackers over the last couple of years, and seems to be more popular now than cross-site scripting or buffer overflow exploits. I would argue that this would not be the case for ASP.NET sites if basic input validation and SQL parameters in combination with stored procedures were employed, as is the recommended practice.

At the very least, even if you are still using ASP and haven't time to convert to stored procedures, check your input data! All input data is evil and when designing your application you should take time to consider where else that input may be coming from, such as query parameters, cookies, etc. Watch this space...

I work in a fairly relaxed development environment. I guess you could call it RAD. Most Web development work is Rapid Application Development by nature anyway. That said, I'm not totally ignorant of the newer methodologies such as Test Driven Development (TDD). However, all the tools and methodologies in existence will not make the slightest bit of difference if your mindset and approach are out of whack for the job at hand.

10 Rules for Debugging - Irish Style

1) Keep it simple, stupid (KISS principle). Many people get in a bind because when given a choice between a simple solution and one that seems more elegant, they of course go for the latter. Elegant code is achieved through experience and refactoring. Get it working first!

2) Divide and conquer. Why look for a needle in two haystacks? Narrow it down.

3) Don't let your emotions get the better of your thinking - always a recipe for disaster.

4) Never panic. Only wimps panic. In the face of insurmountable odds, get drunk, read Hemingway and proclaim your genius loudly to all.

5) Your brain works productively for 40 minutes at a time. This is a universal rule and you are not different. At the 40 minute bell, go away from your desk for 10 minutes as you're only going downhill from that point on. For some strange reason, most people cannot accept this fact. Look around you at work to see who the idiots are. "Gee, I'm sure to get promoted if I never leave my desk"... and pigs will fly.

6) Do not presume that the first change you make to your code that makes it run, is the actual solution. You may have been looking at a symptom...

7) There's a reason why error messages are neither friendly nor helpful. If the guys who penned them were shining beacons of descriptive prose, they would be working for the New Yorker instead of doing that job in the first place. Guess how they get their kicks? Never rely on your bog-standard error message clueing you in to anything other than the onset of an early ulcer.

8) Learn how to think, if you haven't already. I was in my 30's before I started asking the right questions about anything, let alone software development. Ask someone what they really want in life and 90% of the lemmings will reply that "they want to be happy". See where I'm going with this?

9) Creativity is your number one asset. Be creative and learn how to develop new synaptic pathways in that grey matter. The brain needs to be exercised in different ways, regularly. Get out of bed on a different side tomorrow and put your clothes on in a different order. If you really want a laugh, do everything in the washroom with the opposite hand to the one you normally use.

10) As for ASP.NET, if you don't know the life cycle inside-out, you shouldn't be wasting your time skipping a chapter to debugging in the first place ;-)

I recently posted a solution to the eternal PayPal / ASP.NET form submission problem using Jeremy Schneider's custom GhostForm class. Since then, several people have made mention of a problem that I came across myself when coding this, namely getting your project to recognize the reference to the new custom form class.

Using a Web Application Project in VS 2005, I recently came up against something similar when attempting to place the SqlHelper.cs class in the App_Code folder. At that time I offered a quick hack. Since then, I have thought better of using the App_Code folder in my Web Application Projects and just create a normal folder and put the helper class in there along with my data access class. The App-Code is more trouble than it is worth for a small project where there is practically zero compilation time to be saved anyway.

Back to the problem at hand... when attempting to compile, you may get the following error:

"The name 'mainForm' does not exist in the current context"

First, check your scopes; make sure that wherever you are using the mainForm object is in the same scope as the instantiation. Ideally, create a separate Class Library Project in your solution and add the custom form class to it. Compile your new project separately and reference that from your e-commerce project. Right-click the References folder in Solution Explorer and browse to the DLL for the custom form.

Add the following to your master page and ignore any red squigglies you get in Visual Studio:

<%@ Register TagPrefix="CF" Namespace="CustomForm" Assembly="CustomForm" %>
<body>
    <CF:GhostForm id="mainForm" runat="server">
    ...
</body>

Add markup to the ASPX for the dummy PayPal button and a functioning ASP.NET button:

<img src="https://www.sandbox.paypal.com/en_US/i/btn/btn_xpressCheckout.gif"> <asp:Button ID="checkoutBtn" runat="server" OnClick="CheckButton_Click"
    Text="Checkout" Width="100" CausesValidation="false" /> 

using CustomForm;

namespace MyProject
{
    public partial class purchase : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            ...
            // Workaround for PayPal form problem
            GhostForm mainForm = new GhostForm();
            mainForm.RenderFormTag = false;
        }
        ...
    }
    ...
}

Although specific to my own project requirements, here's the complete handler code for the button click: 

        protected void CheckButton_Click(object sender, EventArgs e)
        {
            // Live PayPal URL
            // const string SERVER_URL = "https://www.paypal.com/cgi-bin/webscr";
            // Sandbox PayPal URL
            const string SERVER_URL = "https://www.sandbox.paypal.com/cgi-bin/webscr";
           
            // Live business parameter
            // const string BUSINESS = "grace@graceguitars.com";
            // Sandbox business parameter
            const string BUSINESS = "tester@hotmail.com";

            // Return URL for IPN processing
            const string NOTIFY_URL = "http://www.mysite.com/PayPalReturnURL.aspx";

            decimal totalAmount = 0.00M;
            int productID = 0;
            int totalUnits = 0;
            decimal totalShipping = 0.00M;
            string paypalURL = "";
            string itemName = "Grace\'s Guitars";
            string itemNumber = "";

            if (cart.Count > 0)
            {
                BizClass biz = new BizClass();
              
                // TransactionID will be later used to check against IPN info
                string transID = Guid.NewGuid().ToString();
               
                // Create a new Order in DB
                orderID = biz.AddOrder(out orderID, transID, false, DateTime.Now);
                itemNumber = Convert.ToString(orderID);

                foreach (ShoppingCartItem item in cart)
                {
                    totalAmount += item.Total;
                    totalUnits += item.Units;
                    productID += item.ProductID;

                    // Store order details in database
                    biz.AddOrderDetails(orderID, productID, item.Units);
                }   
                // Eventually, use a SQL Server job to remove unconfirmed orders

                // Calculate total shipping cost for total number of units
                totalShipping = CalculateShipping(totalUnits);

                // Get back the URL-encoded URL for PayPal   
                paypalURL = GetPayPalURL(SERVER_URL, BUSINESS, itemName, itemNumber,
                    totalAmount, totalShipping, NOTIFY_URL);
                Response.Redirect(paypalURL, true);
            }
        }

You need to sign into your PayPal Developer account before submitting your test purchases. You will be able to see a history of your test transactions in the sandbox admin section.

If you want some sample code for constructing the URL, I suggest you check out the following whitepaper from Rick Strahl. This should be enough to see you up and running. Many times, people get compiler errors due to badly-formed namespace declarations and class references. Always double-check your code :-)

GhostForm.zip (448.00 bytes)

I recently started work on my first website to integrate with PayPal. The client needed it done relatively quickly. What started out for me as a mental picture of a products Web form with a "Buy Now" button, somehow turned into a full-blown e-commerce application complete with custom shopping cart. Talk about feature creep! And most of it was my own fault because I failed to anticipate the minimal requirements for the job. I'm still in the thick of it and have just implemented an admin back-end for the merchant to add products, complete with images, to the database. Then, I had to create an HttpHandler to stream the images...

They do say it's the simple things that get you stumped. For all of you ASP.NET developers out there who have yet to integrate a site with PayPal, just wait until you finally get to add that button to your form to pass the transaction details over to PayPal... In short, it won't work! The button HTML from the PayPal site is embedded in a form tag. You can only have one form on an ASP.NET page and ASP.NET provides its own. If you have a master page, then the form tag is in there and it is applied to every page in the site when they are merged with the master at runtime.

PayPal support does not offer a practical solution. They may try to get you to download their ASP.NET SDK which is 1.1 and uses Web Services. Most people have failed to get it to work with 2.0. Then they may tell you to put the form tag "outside" the main tag or on a separate HTML page, etc. I have seen endless hacks, most of which were too stupid to even consider; IFrames anyone?!!

I trudged through the forums and saw that ASP.NET developers have been asking how to get around this for the last three years or so. PayPal refuses to acknowledge the problem and seem more inclined to offer support for the PHP community. There is something radically wrong with this mindset from a business point of view.  Can PayPal not afford to pay some contractors to go in and develop an ASP.NET 2.0 SDK that will work with both NVP and Web Services? Nothing like speed to kill. Then PayPal had the temerity to invite me to complete a survey on how good I found their support service...

So I turned to Google. I spent days concocting search strings that would bring that elusive nugget I needed to solve the problem. I thought I had found it when I came across the nested master page hack - keep the outer master page stripped of any form tag and then just use it for the page with the PayPal button. It would probably work, but if you don't get a code smell from that one, you may need to get your sinuses reamed out. The search continued. You know you're desperate when you start entering your grannie's middle name in the search query string :-O

Persistence finally paid off. I found an elegant solution on Jeremy Schneider's blog that consists of a custom HtmlForm class that can have the form tag rendering toggled on and off. The class is called GhostForm and has a property, RenderFormTag. When RenderFormTag is set to false, it doesn't render the opening or closing tags, but does render all of the contents. Reference the custom GhostForm class and in the code-behind of the form on which you are placing the button, place the following in the Page_Load to disable the master page form tag:

public partial class Products : System.Web.UI.Page
 {
     protected void Page_Load(object sender, EventArgs e)
     {
         GhostForm mainForm = new GhostForm();
         mainForm.RenderFormTag = false;
         .....     
     }
         // Send your data to PayPal :-)
     .....
 }

As promised, here's the final installment. You can find the download links for the final version of the code at the end of this article. Feel free to use this code and tweak it any way you wish. For demo purposes, the menu is on all the pages but you can easily factor this out into its own form. I would normally make this a separate control, but you will probably be integrating this application into your existing navigation anyway, so...

The membership system in ASP.NET 2.0 is pretty much plug-and-play right out of the box. When I worked with it first, I took some time to read up on the new membership controls before trying them out. For this particular topic, I cannot recommend the following two books highly enough:

* Murach's ASP.NET 2.0 Upgrader's Guide (Lowe & Murach)
* Pro ASP.NET 2.0 in C# 2005 (MacDonald & Szpuszta)

Just to recap, at this point you should have a working Guest Book application and database. The only thing left to do is to configure the membership system and add some administration forms to allow us to edit, update, delete and publish comments posted by users.

The next item on our list is to use the WSAT tool to add an admin user, create the admin role and add the new admin user to that role. By using a role, we can grant extra privileges to admin users in the future if needed. We can just do it once rather than having to grant them to each admin user individually. A picture is worth a thousand words, so please refer to the pics for guidance.

Access the WSAT by clicking on the icon at the top of Solution Explorer in VS 2008. Note that the administrator role is already set up in the config file and all you have to do is add the admin user to this role. I'm including a picture showing how to set up the access rule using the tool. The main problem people encounter here is the order of the entries in the authorization section of the config file. The administrator role is listed before 'users'. See the config file picture in part II of this series for clarification.

We will add a new form called guestBookAdmin.aspx to the Admin folder which shows a list of the comments awaiting moderation in a GridView. Clicking on one of these brings up the commentDetails.aspx form. This is almost a replica of the addComment.aspx form which is populated with the data for this comment. The comment ID is passed to this new form when the 'select' link on the guestBookAdmin form is clicked. This is then used as a parameter to the stored procedure when fetching the data for this comment. Note also, that there is now a 'publish' check box. The administrator uses this to put a comment live after it has been edited and approved.

Just a few words about the ObjectDataSource control here. This is an amazingly helpful control which we can use to create a declarative link between our front-end Web controls and our data access methods. Note that our data access class must have a default, parameterless constructor and none of the select or update methods can be static. This is just another reason why I prefer to inject a business layer between the front and back-ends. It gives us a nice comfort zone for future code customizations in the shape of new business rules and the like. Plus, we get to use a more friendly syntax. Ideally, each record should be a custom object but that's another story!! Bring on the new Entity Framework :-)

Be sure to check out the brand new security video tutorials from Scott Mitchell.

Download Code:

GuestBook.zip (99.61 kb)

GuestBook-DB.zip (1.01 kb)