Hi Toolset guys,
I have all my content access restricted based on roles. Each post can only be read by users who has a particular role. It is working nicely.
This is achieved using the Members plugin as Toolset Access unfortunately doesn't support setting the role/Post Group via code.
However, I have now discovered that when you use Layouts and CRED to edit a post, the access restriction is not observed.
So - if I try to read a post (fx hidden link), it is access restricted as expected.
But - if I send the same post to Layouts/CRED (fx hidden link), there is full access to both Read and Update!
Please guide me to solve this issue.
Best
Ken
If I understand you correctly, these User Roles and permissions are defined and managed by the Members plugin, correct?
CRED isn't designed to work within the proprietary permissions systems provided by other plugins. I don't see any information in other forum posts about the Members plugin, so I don't have any great advice here. If I can recreate the issue, I can pass it along to our developers as a compatibility issue between Members and Toolset. Then it may require collaboration with the authors of Members to get a fix in place in both platforms. As you can imagine, this will take some time.
If you'd like for me to get that process started, I'll need to access your wp-admin area to create a clone of your site. Then I can run some local tests and try to replicate the issue on my own local environment. Let me know how you would like to proceed. I have enabled private reply fields here in case you want to share login credentials.
Hi Christian,
Yes, the restriction on post read is achieved using Members plugin.
I would have liked to utilise the Toolset Access module, but two things are missing.
1. I can't assign multiple roles to a user
2. I can't, in code, assign a Post Group to a post (or maybe the other way around) when I create a new post via CRED. CRED has the hook where one could do it, but the info that goes into the post_meta entry is not available.
Members is different. I uses standard WP roles to limit read access to posts, and these can easily be set in the CRED hook.
Before we move to the proposed action, could you let me know if there is a hook somewhere in the chain of events where I can insert a check to see if the post about to be edited by CRED, is allowed to be accessed by the user?
So - somewhere before rendering the edit screen of "layout_id=32" (in the example above), I hook and check to see if the current user has access to the post "online" (in the above example).
Maybe it is simple 🙂
Best
Ken
There's nothing along those lines included in our documented CRED hooks, no. Those are available here:
https://toolset.com/documentation/programmer-reference/cred-api/
I was just browsing the Members readme, and it looks like they offer an inline conditional shortcode called members_access:
hidden link
This looks like it might be helpful. You can use this shortcode inline to manage access to specific content. Surround the entire CRED form in a conditional tag, and define which roles have access to the form. Is this something you have considered?
Hi Christian
Thanks for considering options.
Members_access is a powerful filtering tool and I use it several places. Very similar to the conditional shortcode provided by Tollset.
However, it is merely a filter that filters out/hides what is being shown to the front end user. It will hide any element including a CRED form, but it will not restrict access. If you specify a URL, you can easily circumvent the filter/hide feature.
In fact, I just found out that Layout and CRED is so powerful that it can be tricked into editing even pages without authorization !!!!
If you are a logged in user, any kind and with NO capabilities at all, you can go to fx.
hidden link (where home is the - yes - home page, and layout_id=32 is a Toolset Layout), and then edit the home page of the site. I merely changed the url regarding document -> page and online -> home.
And made this change with a user without ANY capabilities at all!
AND by doing that, it changed the post type of the Home page (std post type Page) into the custom post type (post type Document) that the Layout/CRED form 32 is supposed to deal with.
This gotta be either a major configuration error on my side (I hope) or a major security flaw in Toolset.
I have attached a number of screen dumps to show the above.
Let me know what I need to do to get us closer to finding out, and sorting this mess out.
Best
Ken
However, it is merely a filter that filters out/hides what is being shown to the front end user. It will hide any element including a CRED form, but it will not restrict access.
I see. Let me explain what I was suggesting and you can correct me where I'm wrong. Consider the attached image of a Layout with a Visual Editor cell, which holds a shortcode for the relevant CRED form. This entire CRED form shortcode is wrapped in a members_access shortcode, which prevents it from being displayed to anyone but Editors. This page layout is applied using the URL parameters you mentioned before, and the display of the CRED form is determined by the members_access shortcode. In this case, the guest will not have access to the forum, correct?
I merely changed the url regarding document -> page and online -> home. And made this change with a user without ANY capabilities at all!
Okay I think I see what you're saying. If you use the Layout ID parameter to manually modify the Layout applied to a post, then if that Layout includes an Edit CRED form, then the User can edit the page / post regardless of their status. Let me reach out to my 2nd tier support team to get some clarification here. Please stand by and I will update you when I have some additional information to share.
Hi Christian
Thanks for the update.
I fully understand your suggestion embedding "manage" stuff into members_access.
However, as you can see from the attached, by default when you setup a new CRED Edit form, it creates a Layout and embeds the CRED Edit form in the layout directly.
In this case, nothing is holding ANYONE (logged in users) back from using this CRED Edit form to modify ANY content type - even content not meant to be edited by the CRED Edit form (e.g. pages or other posts). So - basically two major issues here: 1. a user without any kind of WP capability can use the form to edit and 2. can do this on ANY type of post (pages, posts, CPT's).
I did change the default created Layout, removed the CRED Edit form cell, inserted a Visual Edit cell, added the same CRED Edit fom and encapsulated the form shortcode in the members_access. This works fine.
I also found out, maybe you should pass this on to the 2nd tier, that the access to edit (via the above mentioned URL trick) is limited to users that have a role on the post in question. So, in my setup, a user fra company A can't just modify url and view/edit posts from company B. However, a user from company A, only supposed to read a post, can modify the url and edit the post (given that the Layout is not tweaked as described).
This is actually comforting to some extend. However, I do believe someone must look into the issue where you can use these standard CRED Edit forms in standard generated Layouts to edit unrestricted pages and posts (like in my example the home page).
Hope this makes sense. If needed, we can schedule a Hangout with you and/or one of the 2nd tiers and discuss.
Best
Ken
Thanks for the additional information. I'm expecting some feedback from 2nd tier today, and I'll let you know what I find out.
Hi Christian
Having worked with the suggestion I found this related issue.
When you embed the CRED Edit form in a Visual Editor field in the Layout (like suggested above) instead of adding the CRED cell in the Layout, it is not possible to reference it from a View.
Normally you can reference a CRED edit-post link, but you can not target the Layout if it doesnt contain a CRED cell with the CRED edit form.
You can work around this by adding the CRED cell, make the reference in the View and then remove it again - but I doubt that it is meant to be like that 🙂
Anyway - look forward to hearing from you and the team.
Best
Ken
Strike this last remark:
"You can work around this by adding the CRED cell, make the reference in the View and then remove it again - but I doubt that it is meant to be like that ????"
If you remove the CRED cell in the Layout, the View won't show an edit link.
Apologize the confusion.
Hi again
Appear the ticket was marked resolved. Maybe I did it by mistake.
Having worked a bit more with the two ways of using a CRED Edit form in a Layout, I have found the following:
1. as mentioned earlier, if you don't insert the CRED Edit form as a CRED Post Form cell type, it is not possible to reference it in Views - and if you later replace it in the Layout (with a Visual Editor include of the CRED Edit form), the CRED edit link in the View will stop showing.
2. as noted earlier, and believed to be a serious security issue, the Layout with a CRED form inserted as a CRED Post Form cell, doesnt respect the access restriction settings of the site.
3. if you insert the CRED form in a Visual Editor cell in Layouts, this form will correctly check and respect access restriction.
In the attached screen dump, you will see the Layout, an attempt to circumvent access by replacing one post title with another and the result. I shows that the top CRED form (inserted into a Visual Editor cell) notes that the user doesnt have access, while the lower CRED form (inserted into a CRED Post Form cell) disregards the access restriction and wrongly allow the user to read and edit the post.
Thanks, I believe the ticket was mistakenly marked resolved. I have spoken with 2nd tier support and we want to assure you that we will take the security concern seriously and will have a solution as soon as possible. Thanks for the additional information about replicating the issues - I have forwarded that along to the team.
Hi Christian
What is the status on the issues identified?
Have your team been able to replicate and identify the cause?
Thanks
Ken
Hi, our 2nd tier supporters have escalated this issue to our developers as a bug. It has been added to the queue of unresolved issues that our developers need to resolve, and will be prioritized according to its importance relative to other outstanding issues and new feature development. I don't have a timeline for resolution at this point, but I will continue to update you here as I receive new information.
Hi, our developers have provided a bit more information and have explained that the behavior you have experienced is as designed. Here are the notes:
1. as mentioned earlier, if you don't insert the CRED Edit form as a CRED Post Form cell type, it is not possible to reference it in Views - and if you later replace it in the Layout (with a Visual Editor include of the CRED Edit form), the CRED edit link in the View will stop showing.
In the case where you use a Visual Editor cell to display your CRED edit form, you'll need to manually construct your links to the edit form using the appropriate URL parameters. This format can be found in the original links created with the CRED form cell in place. Then you can use inline members_access tags to restrict the visibility of this link and the visibility of the form in the Visual Editor cell.
2. as noted earlier, and believed to be a serious security issue, the Layout with a CRED form inserted as a CRED Post Form cell, doesnt respect the access restriction settings of the site.
CRED does not respond to the standard WordPress User role-based permissions. If you place a CRED edit form on your site in an area that is accessible by Guests, then Guest Users will be able to use that form to edit the related post. This is the expected behavior. The way we typically recommend to restrict that usage is to use Access role-based, post type-based, or form-based permissions, or inline Access Control tags. Since you are using a separate permissions system, the best approach here will be to use the inline member_access tags.
3. if you insert the CRED form in a Visual Editor cell in Layouts, this form will correctly check and respect access restriction.
This shouldn't be the case, unless you have included the inline member_access tags in the Visual Editor cell as well. The form should be displayed to any User with access to the page containing the form, and they should be able to edit the related post or page by submitting the form. If you're seeing something else, I'd like to take a look in the wp-admin area to investigate this.
