If you've written much ASP.NET code since 2005, you've
probably used the built-in role provider, or rolled your own, and written code
that checks whether the current user belongs to a particular role. For
instance, for an article site like ASPAlliance.com, you might choose to show an
Edit link to editors with some code like this:
if(currentUser.IsInRole(Roles.Editor))
{
editLink.Visible = true;
}Of course, it might also be true that authors should be able
to edit their own articles, too.
if(currentUser.IsInRole(Roles.Editor) ||
(currentUser.IsInRole(Roles.Author)
&& article.AuthorId = new Author(currentUser.userId).Id)
)
{
editLink.Visible = true;
}
Oh, but we don't want authors to be able to edit content
once it's been published, only while it's still in draft or submitted status.
if(currentUser.IsInRole(Roles.Editor) ||
(currentUser.IsInRole(Roles.Author) &&
article.AuthorId = new Author(currentUser.userId).Id &&
article.Status != ArticleStatus.Approved &&
article.Status != ArticleStatus.Published)
)
{
editLink.Visible = true;
}
Now of course, this link goes to some page like
EditArticle.aspx, and that page is going to also need to ensure that only authorized
users can access it. Otherwise, even though the Edit link might not be visible
to unauthorized users on the article page, a clever user might construct the
link on their own and still gain access to the edit page. So in your Page_Load
or similar you would end up doing another big ugly if check to see if the
current user is authorized to edit the article. And at this point the code is
extremely ugly and already starting to duplicate itself in your system - it's
starting to smell. The Don't Repeat
Yourself principle bears following, and you can combat repetition in your
logic with abstraction.
