Category: My Projects

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…

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…