We recently had some trouble with AppVeyor, running post-deployment actions after web projects are deployed on our Deployment Agent servers. A good example of this is that I wanted to go ahead and warm up an ASP.NET site after a Deployment Agent finishes deploying the web package. (Why should a user be the first one to wait for ASP.NET to spin up, right?)

AppVeyor has great pre-deployment and post-deployment script support built in. But "post-deployment" to AppVeyor means something completely different when using a Deployment Agent; it really means after the deployment agent job has been queued.

To actually run post-deployment actions on the server that did the deploying, a deploy.ps1 PowerShell script has to be in the root project folder of the deployed web package. See http://www.appveyor.com/docs/deployment/agent#running-powershell-scripts-on-target-server-during-deployment for that.

To get it into the web package, MSBuild has to build it into the web package. For MSBuild to do that, it has to be a part of your project. This means that you would have to add a deploy.ps1 file to your project root in your Visual Studio project. That's great, but it's a bad mix of deployment dependencies and application code. No bueno. And, sometimes you don't control the project, so this must be done during the build process - within AppVeyor.

So, here's my current solution (until AppVeyor supports this as a feature):


This PowerShell script, when run like so...

deploy-script-inject.ps1 -scriptUrl http://something.com/mydeployscript.ps1

... will do the following:

  1. Download the post-deployment script from the -scriptUrl address.
  2. Search for all *.csproj and *.vbproj files recursively in the current folder.
  3. Write post-deployment script as deploy.ps1 to the project's root folder.
  4. Modify the Visual Studio project XML to include the deploy.ps1 file.

After that, it will be carried through to the web deployment package, and AppVeyor's Deployment Agent will see it and run it post-deployment.

To put it all together, add the following lines to an AppVeyor "Before Build Script":

appveyor DownloadFile https://raw.githubusercontent.com/BrandonPotter/AppveyorDeployScriptInjection/master/deploy-script-inject.ps1 -FileName .\deploy-script-inject.ps1

powershell ".\deploy-script-inject.ps1 -scriptUrl YOUR_DEPLOY_SCRIPT_URL_HERE"

That's it - AppVeyor deployment script injection into Visual Studio projects at build time.


Username/password combinations don’t cut it anymore, and Two-Factor authentication is a great way to help secure user accounts. If you have an account with a system that supports it, you should be using it. Likewise, if you develop systems that require users to log in with a username and password, you should be offering it. By using two-factor authentication, you dramatically reduce the attack footprint – no longer would a nefarious individual have to just guess your password, but they would have to guess your password AND a PIN number that changes every couple of minutes.

We are in the middle of adding two-factor auth to a few of our own systems. There are a few sites (like Authy) that will operate this as a cloud service for you at a monthly or usage cost, but there’s no need. Google offers a completely free solution via the Google Authenticator app for iOS and Android, with an equivalent app just called 'Authenticator' for Windows Phone. I was surprised there were no really good libraries to use this method of two-factor authentication in an implementation. So, I made one.

What is two-factor authentication?

Two-factor authentication, as the name implies, requires users to supply normal credentials (a username and password, for example), but adds a second, real-time token to the login to verify the user’s identity.

Old-School Tokens


You may have seen these RSA keys floating around in Enterprise IT departments. These have been around forever, but have normally been a pain to implement and support.

Text Tokens

Some forms of two-factor authentication will text you a one-time unique token when needed. And that is fairly easy to implement. However, text tokens have a few drawbacks:

  • Not everyone is within cell carrier service all the time
  • Text costs can still be prohibitive (when traveling internationally, for example)
  • Sending true text/SMS messages costs money, through services like Twilio

Two-Factor Apps

Fortunately, this problem is easily solved by apps, and Google Authenticator and its similar alternatives are my pick.

There are others, but that should cover most users pretty well.

The workflow on this is straightforward, and can be used offline – tokens are algorithm-generated, and do not require a live internet connection on the user’s device.

  1. Your system/web site/app generates a two-factor token for the user. Perhaps a GUID, or any unique identifier string specific to that user.
  2. You give the user a code to add to the Google Authenticator app, or show them a QR code to scan for the easy way.
  3. Google Authenticator then generates a 6-digit PIN code every 30 seconds. Prompt the user for this code during their login, and validate it!

It looks like this on iPhone:


Try it out!

Go get the app and give it a try to see how it works – I set up a sample workflow here: http://GAuthTwoFactorSample.azurewebsites.net

Scan the QR code into Google Authenticator, and then try validating your PIN code.

Now, on to implementation…

This is supposed to be easy, so start by grabbing the NuGet package GoogleAuthenticator (here’s a link).


Present User Setup QR Code / Manual Entry Code with GenerateSetupCode

Users have two options when setting up a new Google Authenticator account. If using a mobile device, they can scan a QR code (easiest), or they can enter or copy/paste a manual code into the app.

Generating this information takes a couple lines of code:

TwoFactorAuthenticator tfa = new TwoFactorAuthenticator();
var setupInfo = tfa.GenerateSetupCode("MyApp", "user@example.com", "SuperSecretKeyGoesHere", 300, 300);

string qrCodeImageUrl = setupInfo.QrCodeSetupImageUrl;
string manualEntrySetupCode = setupInfo.ManualEntryKey;

GenerateSetupCode requires a couple arguments:

  1. Issuer ID - this is the issuer ID that will appear on the user's Google Authenticator app, right above the code. It should be the name of your app/system so the user can easily identify it.
  2. Account Title – this will be displayed to the user in the Google Authenticator app. It cannot have any spaces (if it does, the library will filter them). The user’s e-mail address is appropriate to use here, if that works for your system.
  3. Account Secret Key – this is the unique user key that only your system knows about. A good length for this is 10-12 characters. Don’t show this to the user! Your users should never see it. I exposed it on the demo site just to show what’s going on.
  4. QR Code Width – width (in pixels) of generated QR code image
  5. QR Code Height – height (in pixels) of generated QR code image

It returns an object with a few notable properties:

  1. QrCodeSetupImageUrl – the URL to the QR code image that the user can scan (powered by Google Charts)
  2. ManualEntryKey – if the user can’t scan the QR code, this is the string they will need to enter into Google Authenticator in order to set up the two-factor account.

Validate a user’s PIN with ValidateTwoFactorPIN

Prompt the user for their current PIN displayed in Google Authenticator, and validate it:

TwoFactorAuthenticator tfa = new TwoFactorAuthenticator();
bool isCorrectPIN = tfa.ValidateTwoFactorPIN("SuperSecretKeyGoesHere", "123456");

That’s it!

About Clock Drift

Given that this two-factor authentication method is time-based, it is highly likely that there is some time difference between your servers and the user’s device. With these PIN codes changing every 30 seconds, you must decide what an acceptable ‘clock drift’ might be. Using the above code samples, the library will default to a clock drift tolerance of +/- 5 minutes from the current time. This means that if your user’s device is perfectly in sync with the server time, their PIN code will be ‘correct’ for a 10-minute window of time. However, if their device time is more than +/- 5 minutes off from your server’s time, the PIN code displayed on their device will never match up.

If you want to change this default clock drift tolerance, you can use the overloaded version of ValidateTwoFactorPIN, and provide a TimeSpan.

That’s all – hope this library is useful and makes two-factor authentication a no-brainer.

Quick, short, and useful ASP.NET feature…

You usually expect that if a user presses Enter while inside a non-multiline TextBox would cause the form to be submitted via your Button on the bottom of the form.

However, if you have multiple “form areas” in your ASP.NET web form, one of the weird “isms” is that the user pressing Enter in one of the fields can have fairly random results, because the browser chooses which Submit button to use, usually based on the order it appears in the HTML. Some conditions will cause your Button_Click event to fire, some not.

A quick and simple way to solve this is to wrap your form section in an <asp:Panel> control, but use the DefaultButton attribute. So…

<asp:Panel runat=”server” ID=”myPanel” DefaultButton=”button1”>
<asp:Button runat=”server” ID=”button1” Text=”This is my button” />


… will cause button1 to be the default “enter key” button when the user is within that panel.