I’m writing some custom application pages that run from the _Layouts directory. They’re triggered by items on the Edit Control Block menu.. (See the previous post from the other day on this option..)
One of the things that has really come up with this is the question of authorisation, and confirming that the user does have the rights for what you’re attempting to do. For the work that I’m doing, this means checking those rights in two places.
The first place is the Edit Control Block that we’re placing the menu option into. This is defined in your elements.xml as a CustomAction. One of the useful features about custom actions, is that you have two elements available to hide them from inappropriate users.
The first is the RequireSiteAdministrator element. This does exactly what it says on the tin, If the current context user is a Site Admin, they get the menu option, if not, they don’t.
RequireSiteAdministrator = "TRUE"
The second option is based on the SPBasePermissions enumeration and is a comma separated list of ALL the permissions that a user must have on a list item before the menu option is shown.
Rights="EditListItems,ApproveItems"
Click here for more information on SPBasePermissions
BUT.. And there is always a but… if your user knows the URL and the format of the query string, they can always type that in directly, so you must include a security wrapper in your application page.
E.g.
try
{
if (sourceItem.DoesUserHavePermissions(SPBasePermissions.ApproveItems) && sourceItem.DoesUserHavePermissions(SPBasePermissions.EditListItems))
{
//Do stuff
}
else
{
throw new SecurityException("You do not have the required rights for that operation.");
}
}
catch (SecurityException ex)
{
SPUtility.HandleAccessDenied(ex);
}
As you can see, we can place the authorisation failure into the try/catch block, and just throw a SecurityException to call the redirect functionality from the SPUtility model. This presents the user with the familiar Access Denied page.
Cheers
Reg.
