Forum OpenACS Development: Re: Commenting for casual browsers

Collapse
Posted by Andrew Grumet on
Okay, great, I'll get an install going with the contrib version.

I realized there's a dark side to using a person object, that bears mentioning.  Because we're dealing with unauthenticated users, we want to give them as little power as possible.  Imagine that we implemented the logic as follows: when a comment comes in having email address mailto:joeuser@rcn.com, we look for a person record a matching email address, create a new person if there's no match, and update other info if there is a match.  Say mailto:joeuser@rcn.com's name is "Joe User".  We'll see that name next to all of Joe's comments.  Now suppose a malicious person comes along and sends a comment as mailto:joeuser@rcn.com but with the name set to "Joe LUser".  Joe's name gets changed everywhere.  Oy.  The helper table approach stores one row per comment, so a malicious impersonation would at worst affect one row.

Don, I think it's reasonable to ask whether opening up comments to unregistered users is good for blogs.  It makes commenting a lot easier which can be both good and bad.  What I can say is that this interface is pervasive in the blog world, so people looking at OpenACS' blog capability would expect it.

Collapse
Posted by Walter McGinnis on
I still think the person route is the way to go.  One way to prevent the scenario (malicous updating of name) that you mention, is to require that someone who is using the same email to make a second comment to become a registered user.

A less intrusive option is to require authentication (i.e. migration from personhood to userhood) when a person tries to update their name.  In both cases I mention, the migration from person to user should require an email authentication.

Ultimately, I think we need more facilities for managing the different flavors of parties in the toolkit.  On the project I'm working on we have an author relation on party_id (along with other similar relations) and we are going to be using users, persons, and organizations as authors, etc.  The trick is how to manage when someone who might be an author joins the site as a user after someone with the same name has already been established as a person in the database by content managers, etc.  Who verifies that this "John Smith" is the same "John Smith" who wrote a book on bike lanes being added to streets that is listed in the content repository?  There are number of possibilies.  Any thoughts?  Perhaps I should post to a new thread.

Collapse
Posted by Tom Jackson on

If you enabled commenting per object you could do some interesting stuff. When a user creates content, they could check a box to enable comments on their content. Then any user/non-user could send a comment which would be 'moderated' by the content creator. In essence, you delegate administration and responsibility to a registered user.