Forum OpenACS Development: Commenting for casual browsers
How can we make commenting easily available to casual browsers? This has come up in other places under the label "anonymous posting." In a recent thread (https://openacs.org/forums/message-view?message_id=160672), a solution was proposed for forums where we simply grant appropriate access to user_id=0 ('Unregistered User'). This is a great solution, lets the permissions system really shine, and works similarly to "Anonymous Coward" systems on other bboard tools.
Weblog comments work a little differently. It's sort of like registration, but simpler. Commenters enter their name, email address, (optional) URL and comment. Then they send everything with a single click. As an example, here is what the interface for Movable Type (MT), a popular blogging tool, looks like: http://grumet.net/weblog/archives/2004/03/09/000688.html.
IMO this interface is pretty friendly and worth copying.
But in order to enable this, we have to figure out where to store the information.
Option #1 is a helper table. Subject to enabling by a parameter, we would assign creation_user=0 to comments by unregistered posters and store name/email/url in a table called "general_comments_unreg_post" whose primary key refers to general_comments.comment_id. This leverages the permission system in the same way as the forums approach described above, but now provides an opportunity to put a name next to every comment.
Option #2 is to provide a low-barrier way to get data into standard system tables. My first thought was to create a "minimal user" with a null password etc. It might work but makes my skin crawl a little. Tracy pointed out that we could create a "person" object instead.
Both options have some implied buildout of general-comments and the packages that consume it. I've partially implemented Option #1. It works fine and doesn't break a huge number of assumptions. Option #2 has the potential to be cleaner, since the person and party tables pretty closely match the data we want to store, but I haven't investigated it carefully yet.
I'm curious to know if other find this interesting, would support it, object, or have other reactions.
I am not sure what you would do about the second message they entered if they had not verified their email address (I guess as long as the account had a null password and had not verified you would let them continue entering data using just their email address).
Anyway, I lean towards #2 as the better solution and really easier in the long run as well.
Also be aware that Dave and Jun are both working on general-comments (the partial work is in contrib) ... is there some possibility of enabling "person" comments and improving the UI or possibly providing an optional "comments lite" UI or the like? General-comments is perceived as needing improvement, which is why Dave started on an improvement project (and why Jun recently joined him), so if at all possible the very best solution would be to fix this general facility.
And comments by unregistered persons such as you describe is an option that other packages might benefit from. If it's good for blogs (are we sure it is? that's another question, I guess) it should be good for photo-albums and similar packages.
The contrib version already support anonymous comments. I had thought about creating a person for unregistered comments in the context of trackback (where a person would actually be a web site, but persons has a URL so this would actually work out nicely.)
I think this is a great idea. Let's coordinate around the contrib version which is fully templated and mostly localized already. As has been stated several times in the past week or two, it needs to be decided how to handle attachments. The file-storage UI seems like overkill for most sites. Perhaps we should have a simpler attachments, maybe we can work on a general API that could allow packages to support both models, or at least optionally hide the file-storage UI.
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:email@example.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:firstname.lastname@example.org'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:email@example.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.
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.
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.
"We've included a throttling measure so that comments from the same IP address can only be posted every N seconds, where N is configurable. We've also added a measure to automatically ban an IP address based on an abnormal number of comments from the same address in a short period of time."
So if you go that route (i.e. not create a person) I'd suggest specializing the general-comment object type as a "unregistered_user_comment" or the like. Note that you end up with exactly the same select queries to grab data but conceptually it's cleaner. Or, if it's not, the object type system is useless :) We should really extend types when that's what we're doing, IMO.
The obvious approach in general-comments, then, would be to create an object of one type or another. I'm assuming that registered users - those logged in at least - have comments posted as they are today.
The query can return the e-mail and similar info with a UNION subselect in the rowset specifier, pulling it either from the person/user table or extended type table. The code would have to guarantee that there's a row in persons/users or the "unregistered_user_comments" type-specific table to guarantee the UNION only returned one row.
I think this would be a really easy feature to add to general-comments.
Two further arguments against the "person" approach:
1. opens a system to a nasty DOS-type attack, if spam is bad just adding comment rows it will be two or three times as hard on the system if a new person is added for each one, and cleaning up afterwards will be at least twice as hard.
2. more code would need to be written - code that needs writing anyway if anyone ever uses "person" - because once you start creating "persons" in the db the user registration code needs to be able to transform them into "users" ...
One of furfly's sites used to have a "email this article to a friend" feature which allowed the user to enter their name and e-mail address, so all users could use it. Someone sent an article about priests abusing children and gave the from address as whodoyouknowwhohasdonethis@somewhere (I forget the domain they used). The recipient took this as harrassment (probably correctly!) and reported it to the police; it came back to us in the form of a subpoena for information about users of the system. The emailing of articles has been deactivated on this site, for obvious reasons, and if the client ever decides to do it again it will only be available to registered users.
The ironic thing about the whole experience was that they were specifically asking for information about people who had access to our mail server, because that's the system it came from. We told our lawyer repeatedly that they were asking the wrong questions, but being a lawyer he wasn't about to volunteer any information to the other side. So I don't think they ever tracked down the person who did this. Whether they should or should not have been able to is of course open to debate, but I was quite amazed by the gross lack of technical understanding among people who were investigating a technology crime.
I like Walter's idea of requiring authentication to update the info. Perhaps it will be a forcing function that gets more party-management code written. Don's right, though, it makes robot attacks worse. Janine, yes this would definitely have to be turn-off-able.
Let me try to think further about dealing with attacks.
At this point I think we'd need to add some features to prevent abuse of anonymous comments.
The other thing I notice andrew mentioned is to make the UI easier. That is simple if we have an includable form in general comments that you can put inline into your package.