• State Verified Answer
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 20 subscribers
  • Views 1954 views
  • Users 0 members are here
Options
Related

How to determine if a user has access to any Verint content type?

Dmitry Mandrichenko

I am developing custom menu widget where admin can set links to any Verint content/application/container (user, group). The configuration contains the identifiers for this content (ContentId, ContentTypeId).

Using these identifiers, the widget calls the Script API and if the user does not have rights to view any content the menu item is not shown for this user.

For this, the content search function was used:

var searchItem = core_v2_searchResult.Get(contentId);

if (searchItem !== null) {
    // show menu item
} else {
    // hide the menu item
}

Calling this function leads to a heavy load on the search service (Solr) for the high-load community, so I am considering any other implementation option.

I am considering the following options to solve the problem:

The following function call initiates an endless page reload if the user does not have permission to access the content (for example, user is a guest):

var content = core_v2_content.Get(contentId, contentTypeId);

Also, for testing, I made plugin based on IScriptedContentFragmentExtension interface, which provides its own function:

var content = se_v1_menu.GetContent(userId, contentId, contentTypeId)

A piece of code that handles access to content:

public Content GetContent (int userId, Guid contentId, Guid contentTypeId)
{
    Content content = null;

    var coreContents = Apis.Get<IContents>();
    var coreUsers = Apis.Get<IUsers>();

    try
    {
        coreUsers.RunAsUser(userId, () =>
        {
            content = coreContents.Get(contentId, contentTypeId);
        });
    }
    catch (Exception ex)
    {
        // ThreadAbortException here
    }

    return content;
}

As with the core_v2_content.Get function, calling coreContents.Get throws a ThreadAbortException and causes the page to reload if the user does not have permission to access the content.

Is there a way to avoid this problem? Or is there another way to check permissions?



Code sample fix
[edited by: Dmitry Mandrichenko at 6:11 PM (GMT 0) on Thu, Dec 9 2021]
Parents Reply Children
  • 0 in reply to Brian Dooley

    Hi Brian, thanks for the answer, yes, I considered this option as the most backup plan. Because in the current API, I cannot find the "universal" permission ID.

    Previously, when using the search API core_v2_searchResult.Get, I could determine if I had read access to any type of content without looking up the permission ID itself.

    This approach ensured that permission check would always work, even under the following scenarios:

    * different major versions of the instance (in version 12 a new type of content was added: "articles")

    * custom content types can be installed on the client instance

    Right now I see the following way to check permissions:

    var permissionId = null;
if (contentTypeId == Types.Group) {
    permissionId = core_v2_groupPermissions.ReadGroup;
} else if (contentTypeId == Types.BlogApp) {
    permissionId = core_v2_blogPermissions.ReadBlog;
} else if (contentTypeId == Types.MyCustomType1) {
    permissionId = dm_v2_myCustomType1.Read;
}  else if (contentTypeId == Types.MyCustomType2) {
    permissionId = dm_v2_myCustomType2.Read;
} else if () {
    // all OOTB content types...
} else if () {
    // all custom content types... 
}

var hasReadPermission = core_v2_permission.Get(permissionId, userId, contentId, contentTypeId);

    Is there a more versatile way to avoid the problem described above?

  • 0 in reply to John Reynolds

    The short answer is that this should not be required to implement the original behavior.

    Internally, there is an approach for checking permission by their "action" such as "read", however, this is used extremely rarely even internally, because of other checks.

    The source of the problem in this use case is that failure of the access denied error being returned on the API entity's error collection as expected. That should be fixed in newer releases, however, I'd like to verify with a more concrete scenario so I can verify that the exact issue that was encountered is resolved and I can provide a resolution version number.

About
Privacy Policy
Terms of use
Copyright 2024 Verint, Inc.
Powered by Verint Community