New user q's (comment system)

Topics: Controls
Sep 7, 2008 at 6:19 PM
I'm testing my first blogengine.net site locally, and I'm finding some oddities with the comment and user systems.
- When I'm logged in to BE I can leave test comments.  When I'm not, it just spins.  I've set up BE to use my domain e-mail, and tested it in the BE control panel.  Is this normal behavior that I can expect to be self-correcting once I've deployed the BE site to the domain?
- I can only select two user roles - Administrator and Editor - and I see no way to add additional roles.  It would be pretty darned nice to have a membership roster and additional roles in the BE system (ideally, roles that can be custom-defined).  Is this a part of ongoing development, or am I just not finding something in the admin tools?

I'm sure I'll have more questions as I become more familiar with BE and ASP.Net, but for right now these seem to be the only BE-related issues that's got me concerned, after fiddling with it for a couple of days on a local test server.
Sep 7, 2008 at 6:29 PM
Followup:  My tests comments (as an unregistered user) did appear when I logged in, and were waiting for approval/deletion.  I'm going to assume for now that my first issue is resolved with an answer of "My hosts actually have the e-mail servers configured properly and they're not allowing mail to be sent from web forms that are not on the domain."

This just leaves, for now, the rather broad question of BE support for user registration.  A multi-tiered account/permission system would allow for digital content/site access subscriptions, either as a paid concern or simply a 'limited access' mechanism, and leaving it out seems like a fairly huge oversight for what otherwise appears to be an excellent tool.  Any information on this?
Sep 8, 2008 at 3:35 AM
Lowgenius,

Glad to hear you cracked the comment issue.  What types of roles were you looking for?  Administrator and Editor pretty much do the job, as BE.NET support multiple authors with safeguards by restricting them to Editor permissions.  If you were looking for a "Reader" role of some type, this could be accomplished through the web.config.  Even commercial apps (like Community Server which licenses for $5000) supports only a blog "Owner" role.  Guess I'm not understanding the issue.

Regards,
Dave
Sep 8, 2008 at 4:46 AM
Hi, Dave, thanks for your response.

Let me preface by saying that I may still be 'thinking in ASP' too much.  For instance, I notice in VSE2008, there is a whole list of user registration/subscription tools built in...but I don't know if/how/how well these integrate with BE.

Let me further state for the record that while I consider myself a pretty doggoned competent ASP/VBScript/SQL developer, when it comes to ASP.Net I'm a blithering idiot and there exists every possibility that I'm trying to make lemonade out of apples here.

I don't have a particular application in mind off-hand, but let's say for instance that I wanted to use BE to manage my small client base - track projects, use as a helpdesk, etc. - which I'm currently doing with a home-brewed system built in ASP Classic over SQL Server. 

So there's an entire subsection of pages that I wouldn't want the 'general public' to access - or even be aware that they exist - but at the same time, I wouldn't want my clients to have access to update my blog or approve/reject comments.  In the ASP Classic app I rolled for this purpose, I have a table of permission definitions, and then each user is associated with a certain permission level.  I've actually implemented this in two layers, so that not only does my site have access restrictions based on permissions, but each client site can also designate other registered users of my site as having edit access to their site.  This came about because of a somewhat unique situation I have where I have one human being who is employed by two clients, but other human beings in the respective organizations also need access to their own sites.

So, if Adam, who works for Company A and Company B, logs in, he can edit content or submit service tickets for both companies.  Adam is the administrator of company A, but only a contributor to company B.  Bonnie is the administrator of company B, but has nothing to do with company A.  They both register at my site; I assign administrative rights, and then Bonnie can go back in and add Adam as a contributor to company B's site.  Meanwhile, here comes Charlie, who Adam just hired as an executive assistant.  Charlie's going to edit both sites under Adam's direction; so Charlie registers an account, Adam sets him to be a contributor to company A, and then asks Bonnie to give him access to company B.  In the end:

Company A:  Adam (a) -> Charlie (c)
Company B:  Bonnie (a) -> Adam (c) + Charlie (c)

As it happens, company B is...let's say a business directory in which clients can edit their own information.  So now you have another user role in the second layer, let's call it Member, and their access is restricted only to editing those records in company B's databases that are directly associated with them.  Since that functionality is a subset of the Contributor functionality, all those members also register at my site, and Bonnie comes along and says "Oh, David, Edward, Frank, and George are all members of company B who can edit their own accounts."  Then with scripting at run time we analyze their permission level and, if they are Members, they can only access certain functionality, and only for records that are directly related to them.  Again, we may have multipe many-to-many relationships here; Dave, Ed, and Frank might all work for member company DEF, but Ed, Frank, and George also work for member company EFG.  PLUS Dave, Ed, and George all work for company DEG.

I'm probably  making this sound way more complex than it is, but you can see where any number of situations might call for this multi-layered user-level + record-level permission scenario.  For example, a web site for local bands to publicize themselves and upload their music; a talent referral service; a real estate advertising service; a website for MMO gamers...the potential applications are limitless, and there are already tons of sites that have already implemented some sort of functionality along these lines.  If I can't do it with BE that's fine - my primary interest in BE is for my personal site, which is far less complicated, and I can easily go with DNN or something else for my business site, or for any more complex application that I might decide to hack at in the future.

So you have this complex, interlocking series of permissions and associations...and I still don't want any of these people to be able to edit my blog :-D  Is this moving waaay outside the scope of BE and more into a tool like DotNetNuke or a commercial CRM system?

-jh
Sep 9, 2008 at 2:27 AM
Lowgenius,

I couldn't ask for a better explanation than the one you provided!

I pretty much do Community Server customization for a living, and I've work for several clients in adding POST-LEVEL permissions, mostly based on authorship.  Roles-based access beyond a two-tiered approach of Administrator-plus-Author at the post-level would add quite a bit of complexity to any blog's architecture.  Administrative permissions remain in these instances, but authors could only add and edit their own posts.  BE.NET is such a light-weight yet robust application, there's nothing that says you couldn't setup multiple instances, with each blog having its own set of users.  This is still not what you're going for, but it's close. 

I didn't do your explanation justice, but I hope you follow-up with your findings.

Regards,
Dave
Sep 10, 2008 at 8:42 PM
Thanks, Dave.  I've deployed my test bed on a SQL Server now, which makes it easier for me to find where the user roles are stored.  I *think* that adding user roles there, in conjunction with the 'post security' extension, might end up being at least a partial solution to this, but honestly I haven't had much time to play with it as my energy is currently focused on more immediate needs, like getting my web hosts to properly configure my server so that it supports ASP 2.0 and the .NET 2.0 (or better, 3.5) framework properly :P.

I'll keep this post bookmarked and try to remember to follow up when I get back into trying to figure it out.