Moot Points

Chronicles of a Software Engineer.

  Home  |   Contact  |   Syndication    |   Login
  3 Posts | 0 Stories | 3 Comments | 0 Trackbacks

News

Archives

Post Categories

Sunday, December 30, 2012 #

If you use Gmail, you may be familiar with Google’s 2-step verification process. It’s an extra verification step using your cell phone. If you turn on the feature, once you enter your username and password, you will be sent a verification code via text message, voice, or Google Authenticator. This is a great way to add an extra layer of security because a malicious user would need your phone as well as your login information.

Now that we’ve established that 2-Step authentication is a good idea, how can we do that in our own applications? “It must be extremely difficult!”

Stop being such a pessimist, its actually pretty easy.

In my last post, I showed GVoiceSharp (a Google Voice API for .Net), lets use that. If you would rather use an officially supported solution since Google does not support an API for Voice, you could go with a paid SMS provider like Twillio, but I prefer free.

Since it’s the easiest to demonstrate, I’m using forms authentication with Web.config credential storage. In the HomeController I’ve added the Authorize attribute to make sure those requests will be routed to the login page, you’ll want to do this on any page that requires authorization.

   1:  [Authorize]
   2:  public ActionResult Index()

Lets look at the AccountController; in the HttpGet version of the Index action, we need to get the return Url provided by forms authentication. We’ll need to carry this forward through the requests so we can return the user to the proper place after being authenticated. I’m storing it in the ViewBag and passing it forward into the form post.

Controller:

   1:  [AllowAnonymous]
   2:  public ActionResult Index(string returnUrl)
   3:  {
   4:      ViewBag.ReturnUrl = returnUrl;
   5:      return View();
   6:  }

View:

   1:  @using (Html.BeginForm(new { ViewBag.ReturnUrl }))

 

The heavy lifting is done in the HttpPost version of the Index action.

   1:  [HttpPost, AllowAnonymous]
   2:  public ActionResult Index(LoginModel model, string returnUrl)
   3:  {
   4:      if (ModelState.IsValid)
   5:      {
   6:          if (FormsAuthentication.Authenticate(model.UserName, model.Password))
   7:          {
   8:              var token = new Random().Next(100000, 1000000);
   9:   
  10:              TempData["UserName"] = model.UserName;
  11:              TempData["TwoStepToken"] = token.ToString();
  12:   
  13:              using (var conn = GVoiceConnectionFactory.Create())
  14:              {
  15:                  conn.Login(ConfigurationManager.AppSettings["GVoiceUser"], ConfigurationManager.AppSettings["GVoicePassword"]);
  16:                  conn.SendSms(ConfigurationManager.AppSettings["SMSNumber"], "Auth Token: " + token);
  17:              }
  18:              return RedirectToAction("SecondAuth", new { ReturnUrl = returnUrl });
  19:          }
  20:          ModelState.AddModelError("", "The user name or password provided is incorrect.");
  21:      }
  22:      ViewBag.ReturnUrl = returnUrl;
  23:      return View(model);
  24:  }

Once the user puts in the correct username and password, we generate a 6-digit authentication token, and send it via SMS using GVoiceSharp. In a real world application we would want to abstract away the SMS provider, making it easier to test, and even change providers. Notice we’re storing the username along with the token, we’ll need it to set the authorization cookie in the next step of the process. I find that storing the authorization token in TempData works best since it persists between requests until its read, then gets cleared out. Another thing to note; I’m storing the login information in the config file, including the outgoing phone number. In a real world scenario, we would want an authentication phone number associated with each individual user.

For the second authentications step, I created a simple model with one property, and some metadata for display and validation purposes.

   1:  public class SecondAuthModel
   2:  {
   3:      [Required]
   4:      [Display(Name = "Authorization Token")]
   5:      public string Token { get; set; }
   6:  }

In the SecondAuth HttpPost controller action, we’re going to accept a SecondAuthModel, along with the return url(again), and check the token against what we have stored in temp data. If everything checks out, we’re going to set the authentication cookie for the specified user, and redirect to the returnUrl.

   1:  [HttpPost, AllowAnonymous]
   2:  public ActionResult SecondAuth(SecondAuthModel model, string returnUrl)
   3:  {
   4:      if (ModelState.IsValid)
   5:      {
   6:          if (TempData["TwoStepToken"] as string == model.Token)
   7:          {
   8:              FormsAuthentication.SetAuthCookie(TempData["UserName"] as string, false);
   9:   
  10:              if (Url.IsLocalUrl(returnUrl))
  11:                  return Redirect(returnUrl);
  12:                      
  13:              return RedirectToAction("Index", "Home");
  14:          }
  15:          return Redirect("/Account/?returnUrl=" + returnUrl);
  16:      }
  17:      ViewBag.ReturnUrl = returnUrl;
  18:   
  19:      return View();
  20:  }

And that’s it, not too hard was it? With just a few extra steps, we added an additional layer of security to our application.

The complete demo application (Mvc2StepAuthenticatio) is available on GitHub. Keep in mind, to run the application, you’ll need to put in your own Google Voice credentials in the appSettings section of the web.config.


Sunday, November 18, 2012 #

There is no official API for Google Voice. However, many of the operations are done via simple rest style http calls, so building one shouldn’t be too difficult.

Digging deeper and rolling your own is always a great way to exercise your problem solving skills and learn new things. So I did just that.

As of the time of writing this, I’m only implementing basic SMS send since that’s all I needed. I’m hoping to implement more functionality in the future.

In my next post, I’ll be using the SMS functionality to implement 2 factor authentication with ASP.Net MVC.


Tuesday, February 21, 2012 #

 With modern frameworks available that were built with loose coupling and separation of concerns in mind, working in WinForms may seem like a testability wasteland. But there are times when the options of WPF with MVVM or MVC on the web are not available, and you’re stuck with WinForms. But fear not, the Mode-View-Presenter pattern is here to save the day!

If you are not familiar with the MVP pattern, the idea is that you have a presenter, which handles all the interactions between the user and the model. The presenter “Talks” to the UI through an abstraction. There are a couple ways of doing the MVP pattern. I’m going to explore the Passive View style, meaning all logic is taken out of the view and moved into the presenter. I’m not going to go into differences in the styles, but if you’re interested, Martin Fowler has in depth descriptions of the Passive View, and Supervising Controller patterns, which are both derivatives of MVP.

I’m going to do a walkthrough for creating a simple MVP application. We need a premise for our demo. I’ll go with something simple, an application that organizes notes. Here our note will be a bit of textual data with a title. Lets implement it.

 

The Model

We need the note and title, as well as created and last edited dates for tracking. We’ll want to validate our model; lets make sure we actually have a note, and I’m going to use files for storage, so we need to make sure we can use our title as a filename:

   1:  public class NoteCard
   2:  {
   3:      [Required]
   4:      [RegularExpression(@"^[_0-9a-zA-Z\s\-_]+$", ErrorMessage="Title cannot contain special characters.")]
   5:      public string Title { get; set; }
   6:      [Required]
   7:      public string NoteText { get; set; }
   8:      public DateTime? CreateDate { get; set; }
   9:      public DateTime? EditDate { get; set; }
  10:  }

 

I also created a repository that will handle the persistence:

   1:  public interface INoteCardRepository
   2:  {
   3:      IEnumerable<string> NoteCards { get; }
   4:   
   5:      NoteCard GetNote(string title);
   6:      bool NoteExists(string title);
   7:      void Save(NoteCard note);
   8:      void Delete(NoteCard note);
   9:  }

 

So, we have a nice way to represent our notes, now we need a way to display it.

 

The View

Our main form has a file menu, a status bar for displaying the number of notes, a list of notes, and a display/edit area for a note.

MainForm

Keep in mind, this form IS our view. We need to abstract away our view by creating an interface that defines the capabilities of our UI:

   1:  public interface IMainView
   2:  {
   3:      event EventHandler NewNote;
   4:      event EventHandler NoteSelected;
   5:      event EventHandler SaveNote;
   6:      event EventHandler DeleteNote;
   7:   
   8:      string SelectedNote { get; set; }
   9:      string StatusText { get; set; }
  10:      string Title { get; set; }
  11:   
  12:      void DisplayMessage(string title, string message);
  13:      void ClearSelectedNote();
  14:      void LoadNotes(IEnumerable<string> notes);
  15:      void LoadNote(NoteCard note);
  16:      NoteCard GetNote();
  17:  }

 

IMainView is a contract that defines the UI, we need to make sure our form fulfills that contract. Since we’re using the passive view style, the implementation will be vary anemic. The only job of MainForm will be translating the messages into UI actions (databinding, manipulating controls, etc.) and notifying interested parties (the presenter) of user interaction:

public partial class MainForm : Form, IMainView

 

The Presenter

Our presenter is going to be doing all the real work. So it will need access to the view and the repository. Since our goal here is loose coupling, we’re going to inject those dependencies via the constructor:

public MainPresenter(IMainView view, INoteCardRepository repository)

We now have enough to write our first test. So lets pause here and write a test before we implement the constructor. To mock the dependencies I’m using Moq.

   1:  [TestMethod]
   2:  public void LoadTest()
   3:  {
   4:      var notes = new[] {"Note1", "Note2"};
   5:      var repo = new Mock<INoteCardRepository>();
   6:      var view = new Mock<IMainView>();
   7:      repo.Setup(m => m.NoteCards)
   8:          .Returns(notes)
   9:          .Verifiable();
  10:   
  11:      var presenter = new MainPresenter(view.Object, repo.Object);
  12:   
  13:      repo.Verify();
  14:      view.Verify(m => m.LoadNotes(It.IsAny<IEnumerable<string>>()));
  15:      view.VerifySet(m => m.StatusText = "2 Notes");
  16:  }

 

We're testing what happens when the application starts. Don’t worry if you’re unfamiliar with Moq, just understand that the test is making sure the the note list gets loaded and the status gets updated upon loading. But I highly recommend checking out the quickstart and familiarizing yourself with Moq.

Now that we have a presenter, lets fill in the constructor and make the test pass:

   1:  _view = view;
   2:  _repository = repository;
   3:   
   4:  view.NewNote += NewNote;
   5:  view.NoteSelected += NoteSelected;
   6:  view.SaveNote += SaveNote;
   7:  view.DeleteNote += DeleteNote;
   8:              
   9:  var notes = _repository.NoteCards.ToList();
  10:   
  11:  _view.LoadNotes(notes);
  12:  _view.StatusText = String.Format("{0} Notes", notes.Count);

 

We’re loading the notes, setting the status, so now our tests pass. And in the real implementation the application works as expected. You’ll also notice we’re wiring up events. This is so we can get notified when the user does something we care about. Lets take a look at one of the handlers:

   1:  private void NewNote(object sender, EventArgs e)
   2:  {
   3:      _view.ClearSelectedNote();
   4:      _view.LoadNote(new NoteCard());
   5:  }

 

As you can see, all we’re doing here is clearing the selection, and loading a blank note. We could easily write a test for this too by using Moq’s RaiseEvent method.

 

Conclusion

Now we have an application that is loosely coupled, largely UI and persistence agnostic, and has well separated concerns. All the things that Engineers love and end users don’t care about. But users do care that an application works, so what we’ve really achieved is testability, which means (hopefully) software that works!

 

Check out the full sourcecode, which is available in my github NoteCards Repository. Now go write some code!