Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.
We have seen what is the association between a security root and a permission, and how secured modules implement this association.
Here we will get to know how permissions are actually used in code.
At some point in your code, you will want to check if the currently logged user can do something. You do this by initiating a permission and using its CheckDemand method.
Actually, there is nothing you have to do. Sitefinity does this for you when it loads your module.
The UI commands you want to disable/hide if a user is not currently permitted to do a task are most probably in the View that displays all items. Very often this will be in a data-bound grid, so you will apply your custom logic on ItemDataBound, RowDataBound or similar events. Here is an example on how to do this (taken from the Lists module):
Here, the Hyperlink has no NavigateUrl if the user does not have CrudRights.View.
Inevitably, a question arises: since I have to Demand a permission before every CRUD operation, shouldn't I implement this in directly in the manager for this module? This depends, but the quick answer is: yes. If you implement it in the manager,
you are sure that an operation can never be performed if a user doesn't have permission. That way, the less things you have to remember, the less chance for making mistakes.
View all posts from The Progress Guys on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.