DNN Forums

Ask questions about your website to get help learning DNN and help resolve issues.

Role conflict - permissions to view pages (DNN 5.4)

You are not authorized to post a reply.

Growing Member

    configured on a user, I have a role that allow to view a page, and another that deny it.
    And in a utopian world, that would violate Kiri-kin-tha's First Law of Metaphysics: "Nothing unreal exists".

    In the DotNetNuke.Security.Permissions.PermissionProvider class, it clearly reads (permissionKey='VIEW'):
    private bool HasPagePermission(TabInfo tab, string permissionKey)
    return (
    PortalSecurity.IsInRoles(tab.TabPermissions.ToString(permissionKey)) || PortalSecurity.IsInRoles(tab.TabPermissions.ToString(AdminPagePermissionKey))
    ) && !PortalSecurity.IsDenied(tab.TabPermissions.ToString(permissionKey));

    Are there any parameters or configurations to change the rule and the allows "winning" on deny?

    Thank you
    PS: yes, I'm on DNN 5.4 :-\

    Veteran Member

      Hard to answer, but DNN 5.4 is the first thing you should get rid of. This is really really old and is more a security hole than it has some.

      Permissions: As in Windows (and quite everywhere) DENY rules. So better leave the state undefined, then it is denied unless it is allowed somewhere else.

      Eg. Group A has View Permissions, Group B not (not denied, but undefined). A member of A can see the page / module..., a member of B cannot (unless he is a member of A as well).

      A has View Permissions, B is denied. Then a member of B cannot see the page, even if he is a member of A. This is the concept.

      Personally, I find it could become very complex if you use Denied, therefore I don't use it (unless it's really really necessary). In most cases, Allow and Undefined are enough.

      Happy DNNing!

      Michael Tobisch

      dnnWerk Austria
      DNN Connect

      Growing Member


        Over the years my company has built a "Data Presentation Server" based on DNN (currently there are about sixty Visual Studio solution projects), whose areas are subject to controlled access through roles.
        Obviously, for consultants who have to configure ad-hoc roles on customers starting from preconfigured roles, it is simpler and more intuitive to have roles that adds the accesses, rather than inheriting the (legitimate) Windows-style policy rules.
        Otherwise it becomes difficult to evaluate which roles deny what, without going to build roles dedicated to each user, losing the advantage of having roles designed for macro application areas.

        I'll have to find a way to apply your advice, so as not to lead to strange behavior.


        You are not authorized to post a reply.

        These Forums are dedicated to the discussion of DNN Platform.

        For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

        1. If you have (suspected) security issues, please DO NOT post them in the forums but instead follow the official DNN security policy
        2. No Advertising. This includes the promotion of commercial and non-commercial products or services which are not directly related to DNN.
        3. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
        4. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
        5. No Flaming or Trolling.
        6. No Profanity, Racism, or Prejudice.
        7. Site Moderators have the final word on approving / removing a thread or post or comment.
        8. English language posting only, please.

        Would you like to help us?

        Awesome! Simply post in the forums using the link below and we'll get you started.

        Get Involved