And that was exacly what I was talkiong about. DNN's 'User Accounts' module does not allow non-admins and non-hosts to manage other users. And that is a big problem. Admins dont typically have time to manage trivial User details on Portals with large number of users (say in excess of 1000).

And that was exactly the reason for a custom Module. Limited User Account Management to Admin support staff without elevating them to the powerful Admin role.

And the Module relied on DNN's infrastructure to provide its services.

I strongly believe that this change should not have been made to the core DNN USerModuleBase class. If DNN's native User Accounts is supposed to be accessible only by Admins or Hosts, then this provision should be made in that module itself, not in the Core code.

The Core code should not dictate these Access privileges in any case. These should be done in the Module that needs to restrict its accesss.

Although the resolution was not that difficult, I simply re-shadowed the UserId property in my module to switch it back tot he old scenario, I again repeat these restrcitions should not belong to the Core but to the modules. And in any case, these should be clearly documneted.

In this entire thread, whenever I say Manage User, I mean a non-Admin with appropriate Edit rights trying to Manage Other users. A User managing himself is a trivial case.

I have created a ticket for it on Gemini.

http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=8623&PROJID=23

---

Rahul Singla
http://www.rahulsingla.com

r_honey,

i recommend you do not do this as it will in all likelyhood make it possible for your users to affect other users, and possibly escalate their account to admin or host level user permissions . The code was put in place to stop this. We may look at creating a custom user permission in a later version and adding it to the check in the userid signature to delegate user permissions, but at present without this check the changes you propose re-introduce a vulnerability.

Cathal

---

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US

I appreciate your sensitivity and your concern regarding the vulnerability I might have introduced. I see your point now. But in any case, as I require non-admins to be able to manage users. what I will do now is to substitute your Permission checking for Host or Admin privilege to just Edit privilege. This should solve the problem, as well as prevent any escalation attack.

Only authorized persons would have Edit rights to the module, and any other attack attempt would lead to a Redirection. Do you think this would solve both problems, allow Non-Admin Editing of users as well as prevent unauthorized access??
 

Yes, at the root level, that was a flaw. Allowing user manipulation without any sort of check. But the solution again was too restrictive. What they could have done is what I have now done. Just check for Edit permissions in the Core class. Then, if a module requires stricter permissions, that could be enforced at the Module level.

Regarding lucky, I would say yes and no. Yes, because DNN 5 offers many features, that I have been looking on for sometine now (and even implemented some in my own custom modules).

No, because I believe DNN 5 to be a water-shed event. Although the core team might have tried for maximum backward compatibility, the proposed features already indicate major breaking changes. That means, you would need to test your modules (and in some cases, even recode them) from scratch.

And this applies to areas some of which would be really painful. Take an example. DNN 4.x has a glbDefualtSkin path for the traditional DNN blue skin. So, we assume that this skin would be the minimum present for any DNN installation. Already in DNN 4.9.0, Blue skin is not provided in the default package. So, that would break all code that falls-back on the Blue skin (I have some modules doing so for some reasons).

So, the minimum I would expect from the Core team would be a port of the Blue skin for DNN 5, even if that is not set as the default skin.

---

Rahul Singla
http://www.rahulsingla.com