A block need not worry about hiding itself if a user shouldn't be allowed to view it. The page framework handles that. However, it does have to check security for other situations. Thankfully securing functionality access within your block is easy to do.

To test whether the current user is allowed to perform a certain action, use the IsUserAuthorized (string action) method where action is one of "View", "Edit", or "Administrate".

Consider a block that might allow the user to edit some content. Before it allows this, or even shows the edit button, it should use the IsUserAuthorized( Rock.Security.Authorization.EDIT )method. Consider this example:

if ( IsUserAuthorized(Authorization.EDIT ) || IsUserAuthorized( Authorization.ADMINISTRATE ) )
{
    rGrid.Actions.ShowAdd = true;
    // ...
}
else
{
    message = "You are not allowed to edit this content.";
}

Since the IsUserAuthorized(...) method is also available on many securable entities in Rock besides Blocks, it can be called to check for authorization against a particular entity. Consider this example where authorization is being checked for a particular group in addition checking general block security:

// user must have EDIT to both the Block and the group
if ( IsUserAuthorized( Authorization.EDIT ) && 
        group.IsAuthorized( Authorization.EDIT, this.CurrentPerson ) )
{
   grid.Actions.ShowAdd = true;
}

Did you notice how we called our "group" object's IsAuthorized() method too?

Here are the standard security actions and their meanings:

Standard security action names

If you need to define additional action names to control your custom functionality, you can simply decorate your block with [SecurityAction(...)] like this:

[SecurityAction( "Cancel", "The roles and/or users that have access to cancel existing orders." )]

This will also cause Rock to include your new action in the Block Security settings window so you can allow or deny particular roles or users to the action.

Block Security modal popup showing a custom "Cancel" action.