For developers: Providers

Secured providers must inherit from DataProviderBase. It has several important members that you should be aware of.

Override to customize the permission sets used by your provider.

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 modify.

Use the following sample to override it:

Returns a cached instance of the security root. You should not have reasons to override this in you modules.

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.

Gets the all the secured objects which inherit permissions, through permissions hierarchy, from a secured object.

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.

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 CMS 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 CMS 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 should be virtual. Sitefinity CMS 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.

In the delete method of a data provider, the developer should call this code:

While this is implemented for the core static modules, you should handle it in your types so that the table sf_permissions_inheritance_map can avoid being flooded with unused ids.