One of the latest features added to Umbraco v5 is a new and improved permissions model. The more I play with this system, the more I realize how powerful it really is. So, in this blog post, I aim to tell you why permissions in v5 rock! =)
NB: Permissions were introduced in Alpha 3, however some of the features listed below are currently only available in the nightly builds.
More Types
In Umbraco v4, if you ever looked at the permissions grid, you’ll notice that each permission related to a context menu item in the content tree. So in v4, permissions basically allowed you to see or not see a specific menu item. In v5, we continue to support this mechanism, but we also allow none menu item related permissions aswell, which pretty much allows us to everything else detailed in this article.
Better Integration
In v5, we not only block access to menu items, but we can also block direct access to the associated controller actions, so even if someone jumps to an editor screen directly, they still can’t get access.
In addition, we also support toolbar buttons to require permissions, which means users only get to see the buttons they have permission to see. Don’t have the publish permission? then you don’t see the publish button =)
And finally, permissions in v5 work with all hive providers, meaning any tree using a hive provider for it’s data source now supports permissions (protected media anybody?), including third party providers. With this addition, it means permissions are no longer just the domain of the content tree.
Multi-User Group Support
In v4, users could only belong to one User Group, meaning that you could end up creating a lot of User Groups with a lot of cross over, just so you could get the right permission level you wanted for a user. Well, in v5, we now have Multi-User Group support, which means a user can now belong to multiple user groups at once. This means you can maintain fewer, more focused user groups, and just add users to, or remove users from, those groups as needed. And if there is any explicit overlap with any given permission, a “Deny” permission, will always take presidence over an “Allow” permission.
Improved UI
We haven’t just looked at the permissions functionality, but also how we go about setting permissions. In v5 we introduced a new permissions grid to make it simpler to see what is going on. On any node in the tree, you can click the permissions option and see the current nodes permissions. The new permissions grid can show you it’s inherited value, and allows you to override a value easily. Additionally, any changes are easily identifiable with the previous value taking on a grey background, and a little icon being added next to the permission name to signify a change.
Custom Permissions
And finally, as with most things in v5, Permissions are extendible. This means, package developers can introduce their own permissions. It’s as simple as creating a class that extends our base permission class, then just use our UmbracoAuthorize attribute on any menu items, controller actions or toolbar buttons you want protected.
Well that’s about it as it stands today, but we are looking to push permissions even further, for example, in the future we’d like to add the possibility of adding permissions to EntitySchemas thus allowing us to allow / deny access to specific properties of an entity.
So hopefully you now see some of the improvements in the permissions model in v5, and how these improvements make the whole system more secure and extendible. And as always, if you do have any questions, don’t hesitate to leave a comment.
