[wp-hackers] "commenter" user role
John O'Nolan
john.wp at onolan.org
Mon Mar 8 02:05:58 UTC 2010
I'm afraid I don't agree with that at all - a user is not a type of
content... that's taking the content type abstraction to a whole new
level!
However you did make one excellent point that a lot of people have
been confusing over the last few days:
"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."
John
On 8 Mar 2010, at 00:17, Mike Schinkel wrote:
> 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
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
More information about the wp-hackers
mailing list