Programming Security: Overview

[This article is part of the documentation preview for the Programming Security section of the Developer manual. You can view the temporary TOC here]

In Sitefinity terms, Programming Security does not mean building a web application that is immune to hackers. Here, rather, we mean that some users can be have limited rights about what they can do for a given module.

For starters, you should refresh your memory about Security in Sitefinity. In a nutshell: users belong to groups (roles), and roles are granted or denied permissions to do basic operations.

What should the end result of a secured module look like? Well, it depends on you, the developer. You could do either of the following

• Hide parts of the user interface if a user is not granted certain permissions
  For example of this approach, try the following: create a new user that has only CmsAccess permission and log in with his/her credentials.
• Apply different style to commands in UI that a user is not granted permission to execute
• Display error messages

In Sitefinity, we call modules that provide security "Secured modules". Actually, we call every object that implements some kind of security a "secured [insert name here]". That being cleared, a secured module needs the following things:

• First and foremost, it needs SecurityRoot
• One or more permission classes
• Use custom permission classes in module to tell if a user is granted permission to perform a task
• Register security root(s) in the module class

If you want to see an example of how to implement a secured module, you can take a look at the sample Contacts pluggable module.