kamagra how much to take

Accessing A SPList, Handling Security Exceptions

When working with a SPList object, it is important that an abundance of possible exceptions is handled with a concise approach that attempts to encompass most, or all, of possible operational failures. For example, in your application you might be examining ala the built-in securable object permission model in SharePoint to toggle certain actions against an arbitrary SPListItem. This is pretty common. I think the most elegant and through approach to this is to define your own list access exception class, then the appropriate static methods to call through the application.

Firstly, let’s define the ListAccessException class that will act as the Exception object.

  1. public class ListAccessException : ApplicationException
  2.  
  3. {
  4.  
  5. public ListAccessException()
  6.  
  7. {
  8.  
  9. }
  10.  
  11. public ListAccessException(string message) : base(message)
  12.  
  13. {
  14.  
  15. }
  16.  
  17. public ListAccessException(string message, Exception innerException) : base(message, innerException)
  18.  
  19. {
  20.  
  21. }
  22.  
  23. }

As you can see, we are super classing the ApplicationException class since this is used when a non-fatal application error occurs. Nothing to fancy here. This is sorta up to your preference; a lot of folks adhere to it being a best practice to inherit from the base Exception class, as stated in this msdn article:

http://msdn.microsoft.com/en-us/library/seyhszts.aspx

Next, let’s define a static method that takes advantage of the above class. This can take many forms, but for example can look like this:

  1. public bool VerifyPermissions(SPWeb web, SPList list, SPBasePermissions permissionType)
  2.  
  3. {
  4.  
  5. bool checkPermissions;
  6.  
  7. web.Site.CatchAccessDeniedException = false;
  8.  
  9. try
  10.  
  11. {
  12.  
  13. list.CheckPermissions(permissionType);
  14.  
  15. checkPermissions = true;
  16.  
  17. }
  18.  
  19. catch
  20.  
  21. {
  22.  
  23. if (permissionType == SPBasePermissions.EditListItems)
  24.  
  25. {
  26.  
  27. throw new ListAccessException("Not Authorized To Edit List");
  28.  
  29. }
  30.  
  31. if (permissionType == (SPBasePermissions.EmptyMask | SPBasePermissions.AddListItems))
  32.  
  33. {
  34.  
  35. throw new ListAccessException("Not Authorized To Add List Items");
  36.  
  37. }
  38.  
  39. if (permissionType == (SPBasePermissions.EmptyMask | SPBasePermissions.ViewListItems))
  40.  
  41. {
  42.  
  43. throw new ListAccessException("Not Authorized To View list");
  44.  
  45. }
  46.  
  47. throw new ListAccessException("Not Authorized To Access List");
  48.  
  49. }
  50.  
  51. return checkPermissions;
  52.  
  53. }

So, in the above, nothing fantastic is happening. We are simply passing our two relevant SPWeb and SPList proxy objects, along with a SPBasePermission enumeration specification to check whether the condition is satisfied or not. If not, wrap and throw the relevant exception. Simple yet useful!

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>