Security problem – Doesn't observe user capabilities.

Actually making this change would break WPUF for me – on my site I want to use WPUF to allow Subscribers to post into a limited set of categories using a simple form. I don’t want them to be able to post anywhere else on the site, or even use the Dashboard (which I’m inhibiting using another plugin) which is why they are configured to be Subscribers.

So if this was changed I’d like to see it as an option.

Even if it is changed to be the same as WordPress defaults you would be able to override it without changing WP User Frontend by using the $can_post filter

$can_post = apply_filters( 'wpuf_can_post', $can_post );

The changes I outline here make this even more versatile as I integrate the user login check into this so you would be able to use this filter to let non logged users post (though I would recommend that this be done with a catcha or similar to stop spam). Note some other changes need to be done to allow this which I’ve included in the updated code mentioned below.

In my case I use this filter to restrict the addition of articles to a custom taxonomy (much like a category) to designated users only. This is somewhat similar to what you are doing.

Once I finished a few more updates the complete code will be posted with the examples of use mentioned. It will also be forked on Github from the main Frontend code source for anyone who wants to use it.

As an aside did you know you can use Frontend to restrict use of the standard WordPress Dashboard? Try the option “Admin area access” in the “Others” tab of the “WP User Frontend: Settings” admin screen.

In any case a new version of Frontend wont break your current installation unless you update and my advice as always is don’t update unless you want to take advantage of new features or to fix security bugs (like this) because 9 times out 10 for customized applications such as yours something always breaks.

Having this as an option on the admin is risking disaster for the general user. The use of the filter is the best way of ensuing security for all.

Hope Ive been helpful but understand I made assumptions about your programming skills and your application that may be astray.

Cheers
TheProfessor

I’ve also noticed that posts are automatically given the post status set by the option “Post Status” in the “Frontend Posting” tab of “WP User Frontend Settings”.

This goes against default WordPress post settings which doesn’t allow contributors to publish posts. Instead their posts are given the status “pending” review.

There are also WP Frontend options to stop all users from editing or deleting posts.

The ideal is that permissions should be initially the same as WordPress defaults with options to override this.

The only thing I think we should do is not allow non-logged in users to post, edit, or delete (although a filter should allow this to allow a programmer to change this with appropriate security measures such as a captcha) as this compromises the security of frontend too much.

So along the lines of current options I propose the following Frontend options.

Default = WordPress defaults
Registered = Logged in users (of any role)

Users who can post?:
Default
Registered
None

Users can edit post?: Users will be able to edit their own posts
Default
Registered
None

Users can delete post?: Users will be able to delete their posts
Default
Registered
None

Post Status: Default post status after user submits a post
Default
Publish
Draft
Pending

Strictly speaking I think “Users can edit” and “Users can delete” are not necessary as “Users can post” can cover this.

Note that if the option chosen for all except post is “registered” then standard WordPress roles will be ignored and “subscribers” will be able to post, edit, and delete their own posts.

If the “Post Status” option is not “Default” then that status will be assigned for all posts and standard WordPress roles will be ignored.
For example if “Post Status” = “Publish” then all posts from Contributors will be published instead of being marked as “pending” which is the standard default for WordPress.

If users want more fine grained control over this they can either

1. Set the options to “default” and install one of the many plugins which manage WordPress roles and capabilities.
2. Write a program which uses Frontend filters to override this.

As I require the above functionality for my application I will add this to my Frontend development fork.

Cheers
TheProfessor

@professor99
Ok, I might have some input. I should mention that I am using the user-role-editor-plugin and the only capabilities that contributors have are ‘read’ and ‘edit-posts.’

So, I added the code (Here’s a screenshot just for reference). You’ll notice that I changed the capability to ‘edit_published_posts’ as I have granted the edit_posts capability to contributors. This code effectively prevents contributors from submitting stories; that’s not the goal but we’re on the right track.

Contributors should be able to:
Submit posts as pending (wpuf handles this well out of the box)
Edit and delete pending posts (There should be a way to utilize the ‘edit_published_posts’ capability to prevent published posts from appearing in the dashboard.)

I think, really, the only thing I need to do is hide the “live” posts on the wpuf dashboard but I’m not having much luck.

Fixed!

To prevent the edit and delete links from appearing in the dashboard for published posts, you only need to amend two lines in wpuf-dashboard.php…

Change line 154 from
<?php if ( wpuf_get_option( ‘enable_post_edit’ ) == ‘yes’ ) { ?>
to
<?php if ( wpuf_get_option( ‘enable_post_del’ ) == ‘yes’ && !in_array( $post->post_status, array(‘publish’) ) ) { ?>

and change line 164 from
<?php if ( wpuf_get_option( ‘enable_post_del’ ) == ‘yes’ ) { ?>
to
<?php if ( wpuf_get_option( ‘enable_post_del’ ) == ‘yes’ && !in_array( $post->post_status, array(‘publish’) ) ) { ?>

Now, this prevents the edit and delete buttons from appearing for published posts for all users. If you would like admins to be able to see the links you would have to alter it some more but anyone who needs to be editing published posts most likely already has back end access.

I hope this helps someone out there and gets more people to download this great plugin.

Thanks Tareq and I’ll hope you’ll consider this issue in future updates.

Thanks heaps gpspake for investigating this and publishing the fix.

I think Version 4.0 of my development release should of fixed this.