PayPal Subscriptions Recently, I blogged about a PayPal Subscriptions project I was working on. This was a website where people could subscribe via PayPal for weekly religious lessons under one of three user categories. The previous post looked at the differences between the Web Site and Web Application Project models and what this meant when attempting to implement user profiles in conjunction with the membership system. Since I had previously created a few basic E-Commerce websites with regular Buy-Now buttons, I thought this would be a breeze... wrong :-|

As part of the project requirements, there would be separate, weekly messages displayed to the subscribers. The first message of a yearly subscription that would be displayed, would be tied to the original subscription date. No matter what kind of subscription system or periodical you are publishing, at some stage you will need to offer the correct issue number to a given subscriber. Since everyone will be subscribing at different times, this means keeping count! I decided to keep a tab of the week numbers. Bear in mind, that week calculations are done differently in different cultures and there is not a bug if you see week number 53!

using System.Globalization;

CultureInfo cultInfo = CultureInfo.CurrentCulture;
int weekNumNow = cultInfo.Calendar.GetWeekOfYear(DateTime.Now,


For the task in hand, I used ASP.NET 2.0 and C# with VS 2005 and SQL Server 2005. It was built as a Web Application Project, which meant using the Web Profile Builder wrapper class to enable access to user profiles. I've heard of several people getting errors with this but it worked for me out of the box. I'm inclined to think that some may have overlooked a particular section of the documentation which I am going to repeat here:

"When your project has reloaded, you need to generate the web profile class and manually include it in your project. Use the solution explorer to do this. In the solution explorer, choose the “Show All Files” option and press the “Refresh” button two times. The first time will generate the profile class and WebProfileBuilder.user file. The second time will actually show the files now that they exist. To include the generated profile class, right-click on the generated profile class and choose “Include In Project”. Now you will be able to write code against the profile class."

The rest is pretty straightforward:

Web.Config Profile Section


public partial class MyClass : System.Web.UI.Page
    private WebProfile Profile
            return new WebProfile(Context.Profile);

    protected void Page_Load(object sender, EventArgs e)
        string subscriberID = Profile.subscriberID;
        string subscriberGroup = Profile.subscriberGroup;


Of course, the glue that holds the entire application together is the IPN class. I had previously used the freely-available IPN class from XDev Software. Note that this class is designed for regular PayPal transactions. I had to customize it to handle PayPal subscriptions. All you really have to do is pare it down to handle only the subscription-related variables you are handling on the return handshake from PayPal. The following set of return variables worked for my particular scenario; you will set these as properties of your custom IPN class:

        string txn_type;
        string business;
        string item_name;
        string payment_gross;
        string payment_status;
        string receiver_email;
        string payer_email;
        string pending_reason;
        string payment_date;
        string subscribe_id;
        string first_name;
        string last_name;
        string custom;


Here's an overview of a typical subscription Web application life-cycle:

1) User subscribes on your site and is directed to the PayPal site where they pay
2) Your IPN class handshakes with PayPal and grabs the values returned by PayPal
3) Your IPN class updates your application database and generates an email to the subscriber with a return URL to register on your site
4) Your IPN class generates an email (backup) to the merchant with the subscription data
5) The subscriber creates a user account on your site and you set up any extra member info you want to store in their profile

protected void Createuserwizard1_CreatingUser(object sender, EventArgs e)
    WebProfile p = WebProfile.GetProfile(CreateUserWizard1.UserName, true);
    p.Initialize(CreateUserWizard1.UserName, true);
    p.subscriberID = ViewState["SubscriberID"].ToString();
    p.subscriberGroup = ViewState["Group"].ToString();


Some Gotchas:

Do not use a return URL from PayPal
Do not mix IPN and PDT. IPN is all you need
Do not forget the Save() method when creating the profile :-S

HTML Markup I don't know about you, but as a Web Developer I sometimes find myself not doing the things I should be doing. The recent rash of SQL Injection script attacks have shown me personally how little thought I sometimes give to where the input is coming from when I'm developing forms.

Then there is the generated markup itself. All our development efforts end up in plain HTML being spit out onto a'page' on a device of some kind. When you consider how sensitive the search bots are to the structure, content and placement of our markup, isn't it amazing that the only time we ever think of it is when we have to generate it dynamically in some code-behind? :-O

If you are using master pages, then you won't want to have duplicate content, in the shape of similar meta tag content, all over your site. So, you will have to generate the meta tags programmatically in the code-behind of the content pages:

HtmlHead head = this.Master.Page.Header;
HtmlMeta meta = new HtmlMeta();
meta.Name = "Description";
meta.Content = "Friendly and relevant content";


You also do not want pages in the secure area of your site to be spidered:

HtmlHead head = this.Master.Page.Header;
HtmlMeta meta = new HtmlMeta();
meta.Name = "googlebot";
meta.Content = "noindex, nofollow";


I recently noticed a big chunk of JavaScript in the markup that I was using to solve the problem of pushing the footer to the bottom of the page, and not relying on copious amounts of needless content and spacers to do the job that CSS cannot. I should have had it in an external file and used the appropiate ASP.NET method to register it and pull it in. So, I created a JS file called footerFix.js, placed it in its own folder and used the following in the master page code-behind:

string myScript = "/js/footerFix.js";
Page.ClientScript.RegisterClientScriptInclude("myKey", myScript);


This created the following markup in my page:

<script src="/js/footerFix.js" type="text/javascript"></script>


Now I have a smaller page, faster download time and a fairly good chance of the spiders actually getting the info they require.


SQL Injection I recently posted about 500,000 sites having been subjected to SQL injection attacks. For the most part, these were old ASP sites. Frankly, I didn't realize there were that many ASP sites still in existence, let alone badly coded! However, both PHP and ASP.NET sites were attacked also. Let's be clear about this: we are talking about bad coding practices here and not about any specific security flaw per-se.

Apparently the saga continues; although I don't have exact figures, there was another rise in attacks in May. Suffice to say that Microsoft saw fit to release a security advisory (954462) on Tuesday, 06-24-2008. Microsoft also enlisted the help of HP to develop a free scanner, called Scrawlr, which can identify whether sites are susceptible to SQL injection. Microsoft also announced the availability of a SQL Injection tool; a static code analysis tool to help find SQL injection vulnerabilities in older Active Server Pages (ASP) code.

 * Microsoft Source Code Analyzer for SQL Injection Tool
 * Microsoft Security Advisory (954462)

You can find plenty of informative links on good coding practices by visiting these two sites, so I'm not going to repeat them here. There is no need for somebody to have a site that is this vulnerable. It's not about spending more money upgrading your version of ASP.NET; it's about employing responsible programmers. The tools mentioned here are basically stopgap measures to buy some time before implementing a more robust solution. What price your data?