DevExpress XAF is a framework for .NET and Visual Studio developers who wants to create Office-like LOB apps for desktop, web and mobile faster and without hiring a large team.
Friday, February 21, 2014
Validation, Conditional Appearance, Security or all modules at once?
I believe this recent discussion in the Support Center will be very interesting for the XAF community.
Let me quote myself from comments to this thread:
Let me comment on the security aspect of this solution. The ConditionalAppearance module (as stated in the docs) should not be used as a security means, even if it can hide or disable certain UI elements. Its primary purpose is to customize the appearance of the application, provide a better UX by guiding an end-user through the predefined application flow (e.g., he or she entered a certain value, then depending on it, new editors appear just for this case or certain editors get disabled not to allow a user to go a wrong way).
So, if you need data protection, you should also have additional security checks (preferably on the server side) and not rely just on the availability of UI controls. For this, I can recommend the following things:
1. Make sure your business logic in data model classes or controllers handles invalid user inputs or other unwanted situations, even if you have set up the Validation or ConditionalAppearance rules for the UI;
2. Use the Security System module to protect your data in the UI or on the server side;
3. Consider hiding your database from the client by using a remote data store service as described in How to connect to a remote data service instead of using a direct database connection;
4. Consider storing the Application Model differences in the database instead of the file system and thus disallowing powerful end-users to customize it manually. See the How to manage user settings (reset, merge, import, export, etc.) stored in the database instead of a file system example for more details.
5. Make sure your application does not allow loading external modules/plug-ins from the configuration file by using the right XafApplication.Setup method overload.
There, of course, may be more things to look at if the final application will be deployed in a banking environment, as in case of the original ticket owner. So feel free to share your feedback on this as well. I know that some of our XAF customers (like Robert Anderson) have production apps working in similar security sensitive environments, so it would be great to hear about your experience. Thanks!
Let me quote myself from comments to this thread:
Let me comment on the security aspect of this solution. The ConditionalAppearance module (as stated in the docs) should not be used as a security means, even if it can hide or disable certain UI elements. Its primary purpose is to customize the appearance of the application, provide a better UX by guiding an end-user through the predefined application flow (e.g., he or she entered a certain value, then depending on it, new editors appear just for this case or certain editors get disabled not to allow a user to go a wrong way).
So, if you need data protection, you should also have additional security checks (preferably on the server side) and not rely just on the availability of UI controls. For this, I can recommend the following things:
1. Make sure your business logic in data model classes or controllers handles invalid user inputs or other unwanted situations, even if you have set up the Validation or ConditionalAppearance rules for the UI;
2. Use the Security System module to protect your data in the UI or on the server side;
3. Consider hiding your database from the client by using a remote data store service as described in How to connect to a remote data service instead of using a direct database connection;
4. Consider storing the Application Model differences in the database instead of the file system and thus disallowing powerful end-users to customize it manually. See the How to manage user settings (reset, merge, import, export, etc.) stored in the database instead of a file system example for more details.
5. Make sure your application does not allow loading external modules/plug-ins from the configuration file by using the right XafApplication.Setup method overload.
There, of course, may be more things to look at if the final application will be deployed in a banking environment, as in case of the original ticket owner. So feel free to share your feedback on this as well. I know that some of our XAF customers (like Robert Anderson) have production apps working in similar security sensitive environments, so it would be great to hear about your experience. Thanks!
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment