Title: Security problem – Doesn't observe user capabilities.
Last modified: August 20, 2016

---

# Security problem – Doesn't observe user capabilities.

 *  [professor99](https://wordpress.org/support/users/professor99/)
 * (@professor99)
 * [13 years, 7 months ago](https://wordpress.org/support/topic/security-problem-doesnt-observe-user-capabilities/)
 * The default install doesn’t observe the standard WordPress user capabilities 
   for the capability “edit-posts”.
 * A User with the capability “edit-posts” should be able to add and edit their 
   own posts. Users without this role obviously shouldn’t be able to do this.
 * In the standard install of WordPress the only user besides non-logged in users
   that are not permitted to add or edit their own posts are users with the role“
   Subscriber”
 * However the default install of WP User Frontend allows users with the standard
   WordPress role “Subscriber” which doesn’t have this capability to add their own
   posts.
 * Note non-logged in users are prohibited from adding posts in WP User Frontend
   so this flaw exists only for users with the “Subscriber” role.
 * So far I have only examined the Add Post functionality of WP User Frontend so
   it is presently unknown if this is the same for Edit Post.
 * Whilst this is only a minor flaw it needs to be fixed in the standard WP User
   Frontend install to conform to the standard WordPress install.
 * To fix manually changed the following code in the file wpuf-add-post.php
 *     ```
       function post_form( $post_type ) {
       ....
         $can_post = 'yes';
   
         $info = apply_filters( 'wpuf_addpost_notice', $info );
         $can_post = apply_filters( 'wpuf_can_post', $can_post );
       ....
       ```
   
 * to
 *     ```
       function post_form( $post_type ) {
       ....
         $can_post = 'yes';
   
         $info = apply_filters( 'wpuf_addpost_notice', $info );
   
          if (!current_user_can( 'edit_posts' ))
            $can_post = 'no';
   
         $can_post = apply_filters( 'wpuf_can_post', $can_post );
       ....
       ```
   
 * If you want to change this default functionality you can use the wpuf_can_post
   filter.
 * Cheers
    TheProfessor
 * [http://wordpress.org/extend/plugins/wp-user-frontend/](http://wordpress.org/extend/plugins/wp-user-frontend/)

Viewing 6 replies - 1 through 6 (of 6 total)

 *  [potterm2012](https://wordpress.org/support/users/potterm2012/)
 * (@potterm2012)
 * [13 years, 7 months ago](https://wordpress.org/support/topic/security-problem-doesnt-observe-user-capabilities/#post-3162102)
 * 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.
 *  Thread Starter [professor99](https://wordpress.org/support/users/professor99/)
 * (@professor99)
 * [13 years, 7 months ago](https://wordpress.org/support/topic/security-problem-doesnt-observe-user-capabilities/#post-3162119)
 * 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](http://wordpress.org/support/topic/close-button-and-return-on-post?replies=4)
   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
 *  Thread Starter [professor99](https://wordpress.org/support/users/professor99/)
 * (@professor99)
 * [13 years, 7 months ago](https://wordpress.org/support/topic/security-problem-doesnt-observe-user-capabilities/#post-3162133)
 * 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](http://wordpress.org/support/topic/frontend-updates-2rrr-fork)
   fork.
 * Cheers
    TheProfessor
 *  [gpspake](https://wordpress.org/support/users/gpspake/)
 * (@gpspake)
 * [13 years, 5 months ago](https://wordpress.org/support/topic/security-problem-doesnt-observe-user-capabilities/#post-3162150)
 * [@professor99](https://wordpress.org/support/users/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](http://i.imgur.com/IR5w6.jpg)).
   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.
 *  [gpspake](https://wordpress.org/support/users/gpspake/)
 * (@gpspake)
 * [13 years, 5 months ago](https://wordpress.org/support/topic/security-problem-doesnt-observe-user-capabilities/#post-3162151)
 * 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.
 *  Thread Starter [professor99](https://wordpress.org/support/users/professor99/)
 * (@professor99)
 * [13 years, 4 months ago](https://wordpress.org/support/topic/security-problem-doesnt-observe-user-capabilities/#post-3162152)
 * Thanks heaps gpspake for investigating this and publishing the fix.
 * I think Version 4.0 of my [development ](http://wordpress.org/support/topic/frontend-updates-2rrr-fork)
   release should of fixed this.

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Security problem – Doesn't observe user capabilities.’ is closed to new
replies.

 * ![](https://ps.w.org/wp-user-frontend/assets/icon-256x256.gif?rev=2818776)
 * [User Frontend: AI Powered Frontend Posting, User Directory, Profile, Membership & User Registration](https://wordpress.org/plugins/wp-user-frontend/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/wp-user-frontend/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/wp-user-frontend/)
 * [Active Topics](https://wordpress.org/support/plugin/wp-user-frontend/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/wp-user-frontend/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/wp-user-frontend/reviews/)

## Tags

 * [add post](https://wordpress.org/support/topic-tag/add-post/)

 * 6 replies
 * 3 participants
 * Last reply from: [professor99](https://wordpress.org/support/users/professor99/)
 * Last activity: [13 years, 4 months ago](https://wordpress.org/support/topic/security-problem-doesnt-observe-user-capabilities/#post-3162152)
 * Status: not resolved