Ticket T241873
Visible to All Users

Security - Provide a way to adjust UI according to the permission changes done through the application UI or directly in the database

Answers approved by DevExpress Support

created 10 years ago (modified 9 years ago)

We have implemented the functionality described in this ticket. It will be included in our next update(s).

Please check back and leave a comment to this response to let us know whether or not this solution addresses your concerns.

Additional information:

Previously, to ensure better performance, security permissions were cached on the first request by default, so that subsequent requests for object access rights are taken from the internal cache. We have received several customer requests to modify this behavior so that the most recent permission info was considered without the cache. In those scenarios, permission data was changed externally by an application administrator who wanted it to be applied immediately without forcing the user to restart his or her app.

Starting with version 15.1.7,  the DevExpress.ExpressApp.Security.Adapters.IsGrantedAdapter class provides the following overloads of the ***Enable***method:
    Enable(ISecurityAdapterProvider securityAdapterProvider) - here ReloadPermissionStrategy  = NoCache is used by default
    Enable(ISecurityAdapterProvider securityAdapterProvider, ReloadPermissionStrategy reloadPermissionStrategy)
    Enable(IEnumerable<ISecurityAdapterProvider> securityAdapterProviders)
    Enable(IEnumerable<ISecurityAdapterProvider> securityAdapterProviders, ReloadPermissionStrategy reloadPermissionStrategy)

The ***ReloadPermissionStrategy***enumeration has the following values:
NoCache - the latest security permissions are loaded from the database for each new XPO Session or EF DbContext. Based on this info, permission request results are calculated and cached. Subsequent permission requests are evaluated using the cache if the XPO Session or EF DbContext object was not changed.
CacheOnFirstAccess - the latest security permissions are loaded from the database only once, on the logon, and are used until the log off or next logon event. Permission request behavior is the same as in the previous mode. This helps avoid extra queries to the database while keeping the correct evaluation of object access permissions.

By default, we provide several built-in implementations of the ***ISecurityAdapterProvider***object, which you can use depending on the used security configuration:
    XpoUICachedRequestSecurityAdapterProvider - for Client-Side Security (XPO UI-level mode)
    XpoIntegratedCachedRequestSecurityAdapterProvider - for Client-Side Security (XPO integrated mode)
    XpoClientServerCachedRequestSecurityAdapterProvider - for Middle Tier Security (XPO)
    EFCachedRequestSecurityAdapterProvider - for Client-Side Security (Entity Framework UI-level mode)

Take special note that to use these features, you must reference the new DevExpress.ExpressApp.Security.EF and DevExpress.ExpressApp.Security.Xpo assemblies to your projects.

To change the permission checking behavior, call the IsGrantedAdapter.Enable method before a user is logged in, e.g. within the constructor of your platform-agnostic module (YourSolutionName.Module/Module.xx) or within the Main function of the WinForms app (YourSolutionName.Win/Proram.xx) or from the Application_Start method of your ASP.NET app (YourSolutionName.Web/Global.xx) respectively. Here is an example for XPO when SecuredObjectSpaceProvider is used:

C#
using DevExpress.ExpressApp.Security.Adapters; using DevExpress.ExpressApp.Security.Xpo.Adapters; IsGrantedAdapter.Enable(new XpoIntegratedCachedRequestSecurityAdapterProvider(), ReloadPermissionStrategy.NoCache);

Once you do this, security permission changes will be queried after the built-in Refresh Action is executed or when a new object DetailView is opened. This guarantees that an end-user will see the application screens updated according to the most recent information. Additionally, the object access permissions by criteria will also be correctly re-evaluated according to the latest data changes.

To better understand this, consider the following scenario: there is a TestObject class with the Name and Description properties. Reading the Name property is always available, while the Description can be read only if Name equals "1":

Previously, to be able to see the effect of a permission after changing the Name property, you had to re-logon the current user as per How do I reset the security permissions cache without logging in again after an administrator has changed user rights?

We would greatly appreciate you downloading official v15.1.7 update and testing this behavior in action with your project to see if it meets your needs.
If this does not fully suit you, please describe the most important use-case scenarios and expected results that you wish to achieve with the security permission checking mechanism.

Thanks,
Dennis

    Show previous comments (10)
    Dennis Garavsky (DevExpress) 9 years ago

      Hello Claudia,

      To process your recent post more efficiently, I created a separate ticket on your behalf: T295636: Questions on ReloadPermissionStrategy.NoCache. This ticket is currently in our processing queue. Our team will address it as soon as we have any updates.

        What's the state of the private https://www.devexpress.com/Support/Center/p/T274268.aspx ticket? I also eperience a very bad performance if using
        IsGrantedAdapter.Enable(new XpoIntegratedCachedRequestSecurityAdapterProvider(), ReloadPermissionStrategy.NoCache);

        Dennis Garavsky (DevExpress) 9 years ago

          @Hurzi!: The changes made when working on that ticket in v15.1.7 are described here. If you are experiencing difficulties with this, please submit a separate ticket in the Support Center, attach a debuggable sample and a test database replicating your problematic scenario, and clarify expected results. We will be more than happy to research your case.

          Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

          Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.