[wp-hackers] "commenter" user role

[Mike Schinkel]

On Mar 7, 2010, at 2:34 PM, Stephen Rider wrote:
> The more security conscious admin right now (generally speaking) does *not* let outsiders register at all -- unless they have specific reason to allow it.

You are unnecessarily conflating "has a record in wp_users" with "having registered as a user."  Commenters would not be registered users, they would have a record in the wp_users table, nothing more.

> The main security concern regarding making all commenters into users is that being a user -- of any type -- is a point of access to the system and a significant step toward hacking the site.  Several times in the past a vulnerability in WP has come up related to Subscribers being able to elevate their own privileges.

So, as I've said, but additional checks in that disallow commenters from logging in. The problem with elevation of privilege is that you let them login at all; put multiple checks in place to ensure they can't login then this becomes a non-issue.

> It's not superstition and it's not some emotional flight of fancy.  When the user elevation bugs cropped up in the past, I'm pretty sure they only applied to sites that actually *allowed* users to register.
> 
> That's not superstition, that's historical fact.  Had all commenters been Users at the time, those vulnerabilities would have applied to any blog with comments.  It's a legitimate concern.

Please address how incorporating multiple checks doesn't resolve the situation?

Anyway, it's becoming clear to me that this issue is becoming much like a conservative debating a liberal or vice versa; both sides have their perspective and both sides are intractable.  

So as I was replying a solution occurred to me that I think will solve almost everyone's issues, especially those that are concerned with security.

Proposal: 
-- Add a "person" post type into WordPress core. 
-- Create a taxonomy called "person-role"
-- Add commenters as posts of post type "person" with a "person-type" of "commenter"
-- Create and maintain a parallel record of post type "person" for each user in the wp_users database.
-- Set  with a "person-type" to "user" for records of post type "person" that are associated with a wp_user.
-- Use wp_users and wp_usermeta only for things related to login and user capabilities.
-- Use wp_post_meta for things like Twitter Screen name, Bio, Photo, etc.

This would solve a myriad of problems. First, it would "harden" the security by making wp_users/wp_usermeta totally focused on security and role management; essentially wp_users conceptually becomes "wp_logins."  It would make wp_posts and wp_post_meta focused on personal, demographic and activity information.  This make it easy to have pages for every person on the site and a whole bunch of other things I can envision but I hope you won't need me to explain (I've already typed too much this weekend.)

>> I was proposing to consider using wp_posts with a post_type of 'user' instead of wp_users. In the case where we keep wp_users and also created a record of wp_posts with a post_type of 'user', they are parallel.  It seems a binary option; how is it not?
> 
> I hope I'm misunderstanding you, because this makes absolutely no sense.  Whether a commenter is a User is one discussion, but are you really suggesting that we define people as a type of POST???

Absolutely, 100% YES.

> That sounds like a very bad, not to mention arbitrary and confusing, idea.  As somebody else commented, this sounds a lot like the Drupal "everything is a node" paradigm.  Can't say I'm a fan.

It's not arbitrary of confusing to me at all. I'm working on a site for a conference right now (a WordPress conference, actually) and it would be a lot easier if users were a post type.

> Think of the web site rule of separation: "HTML for structure, CSS for appearance, JavaScript for behavior".  Different structures for different purposes.  The Posts table is for site content.  Users table for users.  Options table for Options, and so on.

People *are* content. Think of a Facebook page as an example: Photos, URLs (Twitter, Facebook, LinkedIn, etc.), Bios, etc. etc.

Hopefully but proposing what I did above you can see it differently now?

> Philosophically speaking, I actually like the idea of commenters being "Users".  My opposition to it is pragmatic.  People -- actual people -- are a unique element in a site, because they have minds and motives.  The text of a post is never going to spontaneously decide it want to hack my site.  A person might, and thus people have to be treated a bit differently.

My latest proposal rectifies that.

> Personally I prefer my commenters to be "non-entities" as far as the code is concerned.  I value their input, but they don't exist in terms of code, or what Users can and can't do in the system.

If you value their input then I assume you'd want a page where you can see all their comments vs. only seeing their comments littered around the posts.  This latest proposal addresses that.

On Mar 7, 2010, at 2:55 PM, Stephen Rider wrote:
>> BTW, since you're adamant against storing structure in wp_posts, what are
>> your thoughts on how the new menu system stores its data?
> 
> I guest the question to me becomes: Why are we so afraid to add to the database when appropriate?

For me it's not fear to add to the database, it's a desire to use what gives more appropriate functionality.

Personally, the menu items are the things I'd least like to see in wp_posts.  I'd far prefer to see people and comments in wp_posts.

> That being said, others on this list are probably more experienced coders than I am.  But perhaps that in itself speaks to the danger of getting **too close** to the code so that it becomes difficult to step back and see it from the perspective of someone approaching it as new.  The more it's all abstracted, the harder it is to learn and work with.  Just because we're all so close to it, we may make it easier for us but make it a lot harder for new people to approach it.

True, but I don't think this would take us there.

> I found WP *extremely* approachable when I was new to it, whereas having to work with Drupal ("everything's a Node!") is frustrating and confusing.

Drupal is frustrating because of its lack of focus on admin usability and because it maintains control of HTML assembly; WordPress has neither of those problems.  (I worked with Drupal for 2 years before moving to WordPress and leaving Drupal behind.)

Drupal has focused on genericity in the admin UI; WordPress doesn't fall into that trap.  Take the menu designer in WP 3.0 for example. Nowhere does the admin ever see that menu items are stored in the wp_posts table. If it were Drupal, it'd be listed in the node types.

Don't assume improving the architecture forces us to bring along the same problems that other platforms have; the two can be separated.

> I'd rather separate the tables and abstract the functions a bit more (with wrapper functions as needed for both clarity and ease of use).  For a prime example of that I can point to the get_file_data() function that I submitted to WP 2.9 -- now used by both get_plugin_data and get_theme_data.  We could abstract the functions to deal with different tables if necessary, and wrap them in seemingly table-specific functions

I agree that we should separate things when separation makes sense.  

However, we *should* consider putting in wp_posts table if *even a few* of the following add value for the use case:

-- Having a title/body editor for the item has value
-- Having status workflow for the item has value
-- Having visibility control for the item has value
-- Having visibility control for the item has value
-- Having revisions for the item would be valuable
-- Having trash/delete management for the item would be valuable
-- Having ability to schedule publish date/time would be valuable
-- Having a web page of content about the item would be valuable
-- Having ability to define a template for the content page would be valuable
-- Having ability to set another content type as a parent of the item would be valuable
-- Having ability to reference the item in a menu with a menu orderwould be valuable
-- Having category-like terms associated with the item would be valuable
-- Having tag-like terms associated with the item would be valuable
-- Having comments associated with the item would be valuable
-- Having custom fields (meta) associated with the item would be valuable
-- Having images associated with the item would be valuable
-- Having easy URL routing for the item in the form /item-type/%item-name%/ would have value
-- Having an admin menu section for adding and editing would have value
-- Having plugins that support custom content types would add valuable additional functionality "for free."

FWIW, that's a pretty long list.  I can see many of those things being valuable related to people and hence why a person post type in parallel with wp_users and to include commenters makes tons of sense.

OTOH, I'm not certain that menu items really benefit from being there (though maybe they do.)

On Mar 6, 2010, at 11:17 PM, Ptah Dunbar wrote:
> I raised that issue about core post types not using the show_ui argument so if one decides to remove them, Posts,  Pages, and Media would disappear from the UI.

Excellent!

> Outside of that, I disagree that the core post types are really that hardcoded into WP; and if so, then that's probably a bug which you should file a new ticket for.

You are missing the point.  It's not weather or not they are too hardcoded, it's the fact that without being able to remove them few people are ever going to test the edge cases.  If they are removable then its much more likely the edge cases will get tested.  

Its a concern over resultant process and not of the specifics of post being hardcoded.

>> By having (previously) "core" functionality like "Posts" and "Comments" in canonical plugins those broken edge cases are much more likely to be worked out by the core dev team instead of individually by everyone who needs it and has the resources to work on it.
> 
> I'm -1 on canonicalizing "Posts" and "Comments" but I am +1 on removing any hardcoded references to them in core.

Without the former you'll never be able to ensure the latter.

Why would you have an issue with them being default canonical plugins?  I can't see any downside to that.

> Again, version 3.0 decouples a lot of the default posts types (posts and pages) as well as taxonomies (cats and tags) so if you find anything that current still is hardcoded, get it reported so it can be patched.

Many bugs won't be found until decoupling it's easy for anyone to do.

On Mar 6, 2010, at 11:52 PM, Ptah Dunbar wrote:
> The posts table is more like a content types table. But yeah that goes back to the teenager reference. WP needs better semantics :)

Nah, we just need to get comfortable with the semantics we have.

On Mar 7, 2010, at 12:18 AM, Scott Kingsley Clark wrote:
> We definitely agree there! I just think it's funny is all.. Oh,
> wouldn't it be great if "post" (blog reference ftw) wasn't the term
> for content in WP? LOL. 

My experience with Drupal, which refers to nodes as "content" in the admin is just as confusing a "post."  At least we don't have two terms (Drupal = node & content, WP = just post)

-Mike