myjoglog.net – Iteration 3: MVC Membership Provider-based Access Control

In my previous post in this series, I determined that I had to start looking into how MVC handles access control before moving forward. I came up with a list of functional specifications that I needed to write proof of concept code right away to learn how ASP.Net MVC helps (or hinders) me in implementing access control. In this post, I’ll look at the first 2 specifications:

  1. Authenticate individual users and mange their credentials (i.e. a MembershipProvider)
  2. Manage access to functionality based on membership (i.e. a MembershipProvider)

I know that in MVC, controlling access to controller actions (and thereby the associated views) is done via a specific type of ActionFilter called an AuthorizationFilter. Also, the ASP.Net MVC Web Application template includes code that shows how to use an ASP.Net membership provider to enable user registration and login. So, a quick test that will tell me if the built-in AuthorizationFilter will be able to meet the first 2 functional specifications above is to add an authorization filter to the Add action of the Workouts controller so that only users that have logged in will be able to add a workout.

I do this by changing the attribute for the Add method from:

AcceptVerbs(HttpVerbs.Get)

to:

AcceptVerbs(HttpVerbs.Get), Authorize()

Now when trying to add a workout, a user is redirected to the login page. After registering and logging in the user is now able to add workouts!

In the next installment I will try to convince myself that I can control access to actions based on user’s relationship to an entity (i.e. members can only delete their own workouts).

Stay tuned…

myjoglog.net – Iteration 2: User Stories

Creating User Stories

Now that I’ve got a feel for how MVC handles the mechanics of a data-driven application, I’ve got to take a step back and think about how users are going to use the application. For a start, here’s what I came up with:

  • The site will allow anyone (both anonymous and logged in users) to view all recently logged workouts.
  • The site will allow users to create an account and thereby become members.
  • Members will be able to log their own workouts.
  • Members will be able to add events that they are training for.
  • Members will also be able to join one or more teams. A team is a group of members (e.g. that may train together or who are training for the same event).
  • Teammates (members of the same team) will be to see each others’ complete workout logs
  • Teammates will be able to subscribe to updates (i.e. via a feed, e-mail alerts, or iCal) to the logs of their teammates.
  • Only certain members will be able to create, own, and manage a team.

I’m sure these and other stories will get more flushed out as the project evolves, but that’s plenty for now.

Turning Those Stories into Specifications
From these stories I’ve derived some entities (the nouns) that I’ll be working with:

  • Member – a user with an account
  • Workout – um, a workout
  • Event – a race (10K, marathon, triathlon, etc) that a member is training for
  • Team – a group of members

I can see from these stories that the application will need to be able deliver certain functionality that I haven’t yet implemented in MVC. Specifically, the application will need to:

  1. Authenticate individual users and mange their credentials (i.e. a MembershipProvider)
  2. Manage access to functionality based on membership (i.e. a MembershipProvider)
  3. Manage access to functionality based on the user’s relationship (i.e. “owner”, or “teammate”) to a particular entity (workout, member, team, etc)
  4. Manage access to functionality based on roles (i.e. a RoleProvider)
  5. Return content in multiple formats (HTML, rss, iCal???)

That all looks like pretty vanilla stuff for a WebForms application, but I’ll have to convince myself that it will all work out in the MVC world.  So it’s time to write some proof of concept code to convince myself I won’t get stuck.

Stay tuned…

myjoglog.net – Iteration 1: Completing the Workout Life Cycle

So, if you read my first post in this series, you know I’m creating a MVC web application to log and share workouts. Picking up where I left off, I’ve got to complete the life cycle of a workout (insert, select, update, and delete).

Completing the Life Cycle of a Workout

In the first post we covered adding a new workout, and selecting recent workouts. That leaves updating and deleting workouts. To save time we’ll just implement the delete functionality and leave updating for later. To enable deleting all I had to do was add a controller action that would perform the delete operation against the database and add forms to the default view that would post to this controller action.

The new controller action in WorkoutsController.vb:

Note that the action only accepts HTTP POST requests and that it expects the MVC framework to map an input value to a local integer variable called workoutId which it then uses to query and delete the workout record in the database.

The new forms (one for each row) in Index.aspx:

Delete Workout Form

This will write a form that contains a delete button and hidden input for the WorkoutId for each row in the table. Clicking on the Remove button on any row will delete the record and redirect the user back to the home page. You can try it out here:

http://myjoglog.net/workouts/

Wow, that was easy and I was able to implement it in about a dozen lines of code or so. I <3 MVC.

In my next iteration, I’ll create some user stories to see what direction I need to go from here. I know, I know, this is a little backwards. I probably should have started with pen and paper (and what of unit tests???) and then gotten into the code, but MVC is new to me, and I needed to write some code just to understand the life cycle of a page. Besides, better late than never, right?

Stay tuned…

My First ASP.Net MVC Application – http://myjoglog.net

I’ve been very excited about ASP.Net MVC ever since I started hearing about its emergence in various blogs and podcasts. MVC basically addresses all of the issues I have with developing ASP.Net web sites (viewstate, postbacks, testing, etc), and I’ve eagerly awaiting a release its release.

Well, now that ASP.Net MVC is in it’s first beta, I thought it was time to jump in and get my hands dirty with some code. All I needed was an idea for a demo app. My brother-in-law was telling me that he needed an application to log his progress and help motivate him to train for an upcoming marathon. Specifically he said that there are lot of sites out there that allow you to log your own training, but he was really interested in one that would emphasize sharing your logs with your training partners as means to help keep each other motivated. So I started working on a small web application that enables users to log and share their workouts when training. You can follow along as I develop it at:

http://myjoglog.net

Iteration 0: Setting Up the Development Environment

To do create this application on my dev machine, I would need to install ASP.Net MCV Beta (as well as VS 2008 SP1).

I’d also need to find a hosting service that would allow me to host and MVC application (I went with reliablesite.net), and to that end, these threads were helpful:

  1. Step by step instructions for configuring your hosting environment: http://forums.asp.net/p/1239943/2294813.aspx
  2. Which assemblies you’ll need to include in the /bin folder: http://haacked.com/archive/2008/11/03/bin-deploy-aspnetmvc.aspx

Iteration .5: Putting Something Out There

By coincidence (I swear) Stephen Walther and Paul Litwin create a workout log application in their ASP.Net MVC video series. As a first iteration, I thought it would be a good idea to basically go through this series step by step and publish the output on my new hosted. After walking through the steps in the videos, I modified the pages slightly to use the site’s master page, which I also modified a bit to handle navigation for the newly added pages.

You can see the results at: http://myjoglog.net.

Coming Soon… Iteration 1: Completing the Workout Life Cycle

Creating an app that adds and displays data in just a couple of hours (thanks to the help of the template code and tutorials) isn’t too shabby, but there’s lot’s of work to be done. For starters, I want to be able to complete the life cycle of a workout (insert, select, update, and delete). So I’ll do that next.

After that it’s time to take a step back, and review the user stories to get a firm idea of what the app will need to be able to do – this is where my path will diverge from the good start set out by Walther and Litwin. With the big picture in mind, I’ll be able to layout the subsequent iterations that will allow me to get the app fully functional in time to help my brother-in-law train for his marathon.

Stay tuned…