F9 Group Marketing and Technology Blog

Earlier this year I wrote an article about Twitterizer , an open-source .NET library that can be used to integrate your application with Twitter . Using Twitterizer you can allow your visitors to post tweets, view their timeline, and much more, all without leaving your website. The original article, Integrating Twitter Into An ASP.NET Website , showed how to post tweets and view a timeline to a particular Twitter account using Twitterizer 1.0. To post a tweet to a specific account, Twitterizer 1.0 uses basic authentication . Basic authentication is a very simple authentication scheme. For an application to post a tweet to JohnDoe’s Twitter account, it would submit JohnDoe’s username and password (along with the tweet text) to Twitter’s servers. Basic authentication, while easy to implement, is not an ideal authentication scheme as it requires that the integrating application know the username(s) and password(s) of the accounts that it is connected to. Consequently, a user must share her password in order to connect her Twitter account with the application. Such password sharing is not only insecure, but it can also cause difficulties down the line if the user changes her password or decides that she no longer wants to connect her account to certain applications (but wants to remain connected to others)

When a visitor registers a new account on an ASP.NET website that uses the Membership system, they are prompted (by default) for their username, password, e-mail address, and other pertinent information. Along with functionality for registering new accounts, the ASP.NET Membership system provides page developers techniques for modifying information about users. For instance, with just a couple of lines of code you can change an existing user’s e-mail address, approve a user, or unlock them (if their account was locked out). However, there are certain bits of user information that cannot be modified through the Membership API, such as the username. For most sites this is a non-issue. Once a visitor has registered an account that username is fixed; if they want a different username, well, they’ll just have to register a new account. But consider a website that has customized the account creation process so that instead of prompting the user for both a username and e-mail address, the user is only asked to enter an e-mail address and that it is used as both their username and e-mail address on file. Anytime a user switched e-mail addresses – which can happen when changing jobs, changing ISPs, or moving to the new, hip, web-based e-mail provider of the day – they need to also change their username on your site