Hi Don,

no, that's why I added the suggestion to replace buddy roles with user permissions, i.e. you will need an option to specify, for which objects permission shall be replicated using DNN individual user permission.

 Sebastian,

OK, I think I see what you're saying.  Where roles were needed, we would actually assign DNN permissions at the individual level.

Two concerns come to mind regarding this approach: 

• An infrastructure would have to be built to keep faux roles in sync with individual permissions.
• For a large user base, would disk I/O for security related changes be overwhelming?

Thanks again for your thoughts on this,

Don

Just found this thread - as I've implemented a friends system using roles... and I've hit the cookie problem.

In my case I used DNN roles because they looked like they had a convenient structure, API and UI in place... I didn't fully realise (and stil don't) what the longer term implications are.

I don't actually use the DNN roles code to validate "friend" access - I do that in my own SQL....

I could just replace my current friends system with a new one.

However, having read the thread I'm wondering if there's a simple code route around the problem...

Can I just replace DotNetNuke.HttpModules.Membership,MembershipModule with my own IHttpModule - in my case I would probably just limit the contents of the "portalroles" cookie to exclude my friends roles - definitely looks easy enough to do.

If I do this, what other performance risks am I running if I continue to use DNN roles for friends?