DnnModuleAuthorize Attribute Always Returns Unauthorized in Web API

Question

I'm trying to use this attribute on methods in the web API for a custom module:

[DnnModuleAuthorize(AccessLevel = DotNetNuke.Security.SecurityAccessLevel.Edit)]

but no matter what SecurityAccessLevel I set, I always get a 401 unauthorized response.

I was able to make the code work by adding:

[AllowAnonymous]

on the method, and adding:

if (!ModulePermissionController.CanEditModuleContent(this.ActiveModule))
                return Request.CreateErrorResponse(HttpStatusCode.Unauthorized, "You do not have permission to access this content.");

to the beginning of my method, but it seems like this is a workaround that I really shouldn't need because it's exactly what that attribute is there for. I'm running DNN 7.2.1.

Anyone have any idea where I'm going wrong with the attribute?

Answer 1

Turns out it was actually related to the anti-forgery token. I'm using Angular so I'm setting my headers manually in my Angular service rather than using the built-in ServicesFramework setModuleHeaders method and was only setting the TabId and ModuleId. I didn't think the [AllowAnonymous] attribute would override the anti-forgery stuff but it looks like it definitely does (which is good to know).

Full solution for those doing the same:

var baseUrl = sf.getServiceRoot('[yourmodulename]') + '[controller]';
    var config = {
        headers: {
            'ModuleId': sf.getModuleId(),
            'TabId': sf.getTabId(),
            'RequestVerificationToken': sf.getAntiForgeryValue()
        }
    };

Answer 2

Do you have the SupportedModules attribute applied to your controller (or action method)? If so, I'd guess there's a mismatch between the name you're passing in there and the real name in DNN (you should be passing in the desktop module name). Try removing that attribute and seeing if it helps.

The same process that sets ActiveModule and the current user (and would thus make your check in the action method work) should be responsible for implementing the DnnModuleAuthorize attribute's check. So, that's definitely perplexing. Maybe that changed, and if you just pass ModuleId but not TabId in the headers, then it sets ActiveModule, but won't authenticate?

Have you looked at the traffic in Fiddler and made sure that the ModuleId and TabId headers are being sent correctly? Does being logged in as a super-user (i.e. host-level user) affect any of the auth checks (if so, perhaps the URL isn't being constructed properly, and DNN is identifying the wrong portal)?

Answer 3

When you initialize the ServicesFramework, make sure you do it inside a document.ready function.

    var self = {};
    jQuery(document).ready(function ($) {
        self.sf = $.ServicesFramework(<%=ModuleID %>);
    });

More info: www.dnnsoftware.com/forums/threadid/507753/scope/posts/services-framework-problems