Providers
This topic contains the following sections.
Inherit from DataProviderBase
This section contains the following subsections.
Secured providers must inherit from DataProviderBase. It has several important members that you should be aware of.
GetSecurityRoot
Return the security root of the permissions inheritance. It is responsibility of the decorator to implement this.
SupportedPermissionSets
Override to customize the permission sets used by your provider.
/// <summary>
/// Gets the permission sets relevant to this specific secured object.
/// To be overridden by relevant providers (which involve security roots)
/// </summary>
/// <value>The supported permission sets.</value>
/// <remarks>
/// Default supported permission sets for the News module are General and Comments.
/// General is used for News items and Comments is used for comment related to news items.
/// </remarks>
public override string[] SupportedPermissionSets
{
get
{
if (this.supportedPermissionSets == null || this.supportedPermissionSets.Length == 0)
{
this.supportedPermissionSets = new string[]
{
SecurityConstants.Sets.General.SetName,
SecurityConstants.Sets.Comments.SetName
};
}
return this.supportedPermissionSets;
}
set
{
this.supportedPermissionSets = value;
}
}
/// <summary>
/// Use property instead of direct access.
/// </summary>
private string[] supportedPermissionSets;
SetRootPermissions
Sets default permissions (using the general permission set). Reasonable defaults are set: everyone is allowed to view items and backend users are allowed to create and delete.
If the security root supports comments, everyone will be allowed to create and view them, but only backend users will be able to delete and mofify.
Here is how you can override it:
/// <summary>
/// Sets the root permissions.
/// </summary>
/// <param name="root">The root.</param>
public override void SetRootPermissions(Sitefinity.Security.Model.SecurityRoot root)
{
if (root.Permissions != null || root.Permissions.Count > 0)
root.Permissions.Clear();
var securityCong = Config.Get<SecurityConfig>();
var everyoneId = securityCong.ApplicationRoles[SecurityConstants.AppRoles.Everyone].Id;
var backendId = securityCong.ApplicationRoles[SecurityConstants.AppRoles.BackendUsers].Id;
var ownerId = securityCong.ApplicationRoles[SecurityConstants.AppRoles.Owner].Id;
// comments
var permissionsForEveryoneToCreateComments = this.CreatePermission(SecurityConstants.Sets.Comments.SetName, root.Id, everyoneId);
permissionsForEveryoneToCreateComments.GrantActions(false, SecurityConstants.Sets.Comments.View, SecurityConstants.Sets.Comments.Create);
var permissiosForBackendUsersToModifyAndDeleteComments = this.CreatePermission(SecurityConstants.Sets.Comments.SetName, root.Id, backendId);
permissiosForBackendUsersToModifyAndDeleteComments.GrantActions(false, SecurityConstants.Sets.Comments.Modify, SecurityConstants.Sets.Comments.Delete);
root.Permissions.Add(permissionsForEveryoneToCreateComments);
root.Permissions.Add(permissiosForBackendUsersToModifyAndDeleteComments);
// News
var permissionsforEveryoneToViewNewsItems = this.CreatePermission(SecurityConstants.Sets.General.SetName, root.Id, everyoneId);
permissionsforEveryoneToViewNewsItems.GrantActions(false, SecurityConstants.Sets.General.View);
var permissionsForBackendUserstoCreateNewsItems = this.CreatePermission(SecurityConstants.Sets.General.SetName, root.Id, backendId);
permissionsForBackendUserstoCreateNewsItems.GrantActions(false, SecurityConstants.Sets.General.Create);
var permissionsForOwnersToModifyAndDeleteNewsItems = this.CreatePermission(SecurityConstants.Sets.General.SetName, root.Id, ownerId);
permissionsForOwnersToModifyAndDeleteNewsItems.GrantActions(false, SecurityConstants.Sets.General.Modify, SecurityConstants.Sets.General.Delete);
root.Permissions.Add(permissionsforEveryoneToViewNewsItems);
root.Permissions.Add(permissionsForBackendUserstoCreateNewsItems);
root.Permissions.Add(permissionsForOwnersToModifyAndDeleteNewsItems);
}
SecurityRoot
Returns a cached instance of the security root. You should not have reasons to override this in you modules.
AddPermissionToObject
If secured object and permission are created in different providers, this will use a common transaction to safely add a permission to the secured object. You don't need to override this, as this is responsibility of the decorator.
GetPermissionsInheritors
Gets the all the secured objects which inherit permissions, through permissions hierarchy, from a secured object.
PermissionsetObjectTitleResKeys
Gets a dictionary:
- Key is a name of a permission set supported by this provider
- Value is a resource key of the SecurityResources title which is to be used for titles of permissions, if defined in resources as placeholders.
Usage of this property is covered in detail in the topic for permission labels.
Apply security attributes to methods that perform CRUD operations
Security-related attributes will be discussed in greater detail, but here is an overview on how you should apply them in your providers: PermissionAttributes#SampleUsage
The general idea is that you have to map provider methods to security actions, this informing Sitefinity what permissions to check when certain methods are invoked.
 Note |
| You probably noted the CommitTransaction override. While we don't add any functionality, we add a new attribute. Sitefinity works in transactions, and certain permissions checking is possible at transaction commit time only (e.g. modify). |
 Important |
| Methods that have attributes applied on them sould be virtual. Sitefinity's security engine uses method interception, and for this to work, your classes are overriden in dynamic modules. If your methods are not virtual, the IoC framework we use wouldn't be able to override them, thus interception won't work. As a result of this, security (automatic demanding)will not be applied. |