Access options not working

Are the other users site admins? (Site admins can do anything.)

But regular users shouldn’t be able to access or edit your protected docs. You might try making a “normal” user to test access with. If you are able to access docs you shouldn’t be able to, then maybe a filter in a plugin or your theme is breaking WP’s user_can permission check logic that BP Docs relies on.

Try searching your plugins directory for 'map_meta_caps' to see what plugins are filtering on that hook. (Or deactivate all plugins except BP and BP Docs to be sure that the access protection works, then add plugins one at a time until it breaks.)

• This reply was modified 3 years, 9 months ago by David Cavins.

Unfortunately, we have not been able to find the problem, and it persists. We are still not able to make docs private at https://youthvoices.live

To check this issue in more detail the tech team at Fixrunner moved our website to their staging platform and disabled all plugins and changed the theme. Still the issue is existing on the site. They are convinced that this is a plugin related issue and they recommend contacting you to to check this issue in more detail.

I have attached the staging details for reference. I created this admin account for you: username: bpdocs password: DavidCavins123
https://youthvoices47637.e.wpstage.net/
Wordpress admin URL: https://youthvoices47637.e.wpstage.net/wp-admin

Can you please take a look and help out with this problem? For our students to be able to write privately is quite important, and I’m a bit concerned that we have been telling them that their work is private when it is not.

I love BuddyPress Docs, and I want to help make it work on our site. Can you help?

Should I wait on a response here? I would really like to see this working, and I’ve put forward a good faith attempt to find out why the access module on BP Docs is not working. PLEASE ADVISE.

I found this message on the staging site where we had changed the theme and disabled all plugins except BudyPress Docs — with the problem persisting.

Your BuddyPress Docs attachments directory is publicly accessible. Doc attachments will not be properly protected from direct viewing, even if the parent Docs are non-public.

It looks like you are running Apache. The most likely cause of your problem is that the AllowOverride directive has been disabled, either globally (httpd.conf) or in a VirtualHost definition. Contact your host for assistance.

See this wiki page for more information.`

https://github.com/boonebgorges/buddypress-docs/wiki/Attachment-Privacy#apache

I don’t understand what this is asking me to do — or check? Is this something my host will know what to do with?

Please advise. I don’t want to give up on this plugin.

I had the tech team at Bigscoots look into the problem. Here are two of their responses:

It looks like the plugin is failing to detect the proper web server as we using nginx on our WPO plan.

That being said, I’ve gone ahead and added the necessary location block as shown here:

https://github.com/boonebgorges/buddypress-docs/wiki/Attachment-Privacy#nginx`</blockquote>

AND

<blockquote>This would be an application issue then and not a server side issue. The server itself cannot distinguish users in a database, that is up to the application.

The nginx rule we added makes it so if someone requests a file from:

https://youthvoices.live/wp-content/uploads/bp-attachments/12345/somefile

it routes the request through WordPress which would be handled by the plugin, the plugin then has to decipher how the file is then handled.`

Please note that we have done everything we can to fix this from our end. We have eliminated the possibility that the problem is a conflict with the theme or with another plugin. We have confirmed that there is not a problem with the way the site is being hosted. Both tech teams — from Fixrunner and Bigscoots — are convinced that the problem is “an application issue.”

I just want to restate, that I’m staying in here, because I really value this plugin and I want to see it work — not just for my site but for the community of WordPress users.

I would think you would want to get to the bottom of this too?

> I would think you would want to get to the bottom of this too?

Hello, and thanks for your patience as the two volunteer maintainers of this plugin provide what assistance they can. I understand that this issue is important to you and your community, but it’s not possible for us to provide full debugging and troubleshooting service to all users of the plugin, nor to guarantee lightning-quick support turnaround that you might rightly expect for paid products.

It’s unlikely that the nginx configuration is the source of the issue. Those warnings are specific to *attachments* – images, pdfs, etc – and it sounds like you’re talking about access to WP pages (ie, the Docs themselves).

As such, it’s likely that the problem comes from the capability schema that @dcavins alludes to earlier in the thread. The specifics depend in part on exactly what’s happening on your site – your original report doesn’t really give the necessary details. For example, one sort of problem is that you have a Doc with the URL example.com/docs/abcde; this Doc has the “members only” setting; when you visit example.com/docs/abcde as a logged-out user, the Doc incorrectly loads. Alternatively: when looking at a list of Docs, you see ‘abcde’ in the list and are able to click the Doc title. Or perhaps some other behavior.

There are a few possibilities:

1. The access settings aren’t properly being saved. When you make access level changes while editing a Doc, does it stick? When the page refreshes, do you see the access levels remain?

2. The ‘template_redirect’ hook that’s meant to protect individual Docs is not working. The symptom here would be that you’re able to access a Doc via URL instead of being redirected to wp-login.php when not logged in. The operative part of the plugin is https://github.com/boonebgorges/buddypress-docs/blob/297a9d11239ca6bd28e6f8959b0d061823e249a3/bp-docs.php#L69 and https://github.com/boonebgorges/buddypress-docs/blob/297a9d11239ca6bd28e6f8959b0d061823e249a3/bp-docs.php#L603 Are these parts of the plugin being triggered?

3. Capability mapping is not working for some reason. This is what @dcavins is suggesting. Here’s the part of buddypress-docs responsible: https://github.com/boonebgorges/buddypress-docs/blob/297a9d11239ca6bd28e6f8959b0d061823e249a3/includes/caps.php#L27

I just did a brief test using the credentials you provided, and it’s not obvious to me what the problem is.
a. Using the bpdocs login, I created the Doc https://youthvoices47637.e.wpstage.net/docs/test-access-doc/ and set ‘Read’ permissions to ‘Logged-in users’
b. As a non-authenticated visitor (ie in another browser), I visited https://youthvoices47637.e.wpstage.net/docs/test-access-doc/
c. As expected, I was redirected to the login page.

So I guess the next step is to provide as much information as possible on how we can reproduce the problem that you’ve described.

1. The access settings aren’t properly being saved. When you make access level changes while editing a Doc, does it stick? When the page refreshes, do you see the access levels remain?

My answer to 1: Yes the access levels remain. They are sticking.

2. The ‘template_redirect’ hook that’s meant to protect individual Docs is not working. The symptom here would be that you’re able to access a Doc via URL instead of being redirected to wp-login.php when not logged in. The operative part of the plugin is https://github.com/boonebgorges/buddypress-docs/blob/297a9d11239ca6bd28e6f8959b0d061823e249a3/bp-docs.php#L69 and https://github.com/boonebgorges/buddypress-docs/blob/297a9d11239ca6bd28e6f8959b0d061823e249a3/bp-docs.php#L603 Are these parts of the plugin being triggered?

My answer and a question about 2: This is the doc that I’ve been testing with. Only the read is open to all, everything else is private for the author only:
https://www.youthvoices.live/docs/agree-disagree-response/ A logged out user only can read the document. That’s what I want for a regular logged-in user as well, but when I log with these credentials yeury.nicasio – 220732879 I can go to the Docs directory (It’s available on the main menu). Find the document and edit it — which a regular user should not be able to do.

I don’t know how to answer the question: Are these parts of the plugin being triggered? I will pass that on to Fixrunner and Bigscoots teams and get back to you.

3. Capability mapping is not working for some reason. This is what @dcavins is suggesting. Here’s the part of buddypress-docs responsible: https://github.com/boonebgorges/buddypress-docs/blob/297a9d11239ca6bd28e6f8959b0d061823e249a3/includes/caps.php#L27

My answer to 3. I think these questions were answered because Fixrunner deactivated all plugins except buddypress-docs and they changed the theme and the problem presists.

I just did a brief test using the credentials you provided, and it’s not obvious to me what the problem is.
a. Using the bpdocs login, I created the Doc https://youthvoices47637.e.wpstage.net/docs/test-access-doc/ and set ‘Read’ permissions to ‘Logged-in users’
b. As a non-authenticated visitor (ie in another browser), I visited https://youthvoices47637.e.wpstage.net/docs/test-access-doc/
c. As expected, I was redirected to the login page.

My answer to your test: The problem is not with non-authenticated visitors. The problem is with authenticated, logged in users. They can edit all private docs.

So I guess the next step is to provide as much information as possible on how we can reproduce the problem that you’ve described.

I totally — and personally — understand the volunteer nature of much of this work. And I do appreciate what you have done so far.

Does this move the ball forward?

I checked with my host and they sent me this message:

While I understand, I’m not sure how we can truly determine if they are being triggered or not. This would be more up to the plugin developer to initiate some kind of logging that records what’s triggering during those events.

I asked a tech team at Fixrunner to help and I received this response.

Can you please ask the plugin developers how to check this?

I could not figure out a way to check if those functions are triggered or not.

Can you help me with #2 in your possible problems and log whether “these parts of the plugin being triggered?”
https://github.com/boonebgorges/buddypress-docs/blob/297a9d11239ca6bd28e6f8959b0d061823e249a3/bp-docs.php#L69 and https://github.com/boonebgorges/buddypress-docs/blob/297a9d11239ca6bd28e6f8959b0d061823e249a3/bp-docs.php#L603

It doesn’t appear that any of my technical support teams can do this.

Thanks.

> I could not figure out a way to check if those functions are triggered or not.

I was vague about this because I wasn’t sure whether you or your team had the technical knowledge to set up debug statements. It sounds like the only way for hands-on debugging to take place would be for you to work with a consultant who had server-level access to your installation.

In the meantime, I was not able to test using the production credentials you offered (I couldn’t log in) but I did set a test document on the staging site: https://youthvoices47637.e.wpstage.net/docs/test-access-doc/, which has Read access to ‘anyone’ and everything else locked down to “author only”. I then created a new user testuser123 that has only the Contributor status on the site, and then attempted the following as testuser123:
– Visit https://youthvoices47637.e.wpstage.net/docs/test-access-doc/. As expected, I do *not* see any links to edit the Doc.
– Visit https://youthvoices47637.e.wpstage.net/docs/. I can see the list of Docs, but, as expected, no Edit links
– Visit https://youthvoices47637.e.wpstage.net/docs/test-access-doc/edit/, the direct URL of the edit interface. As expected, I was redirected back to https://youthvoices47637.e.wpstage.net/docs/test-access-doc/ with the error message “You do not have permission to edit the doc”.

So the system is working in general. It’s possible that the specific combination of documents and users that you’re testing with is triggering the issue.

Note that WP users with the role Administrator can edit all Docs, even those that are flagged “Author only”. Be sure that you are testing with an account that does NOT have Administrator status.

THANK YOU!
I’m aware of the difference between the Admin roles and the regular user roles. (On Youth Voices the “author” role is our regular user.) I have been testing from a regular user’s login.
What your test revealed — and I hadn’t seen before — is that when a user joins the site without the “Author” role they are a “Contributor.” As a Contributor your testuser123 could not edit the test Doc that you created.
When I added the “Author” role to this user, however, they could edit.
Duhhh… So this might all be as simple as finding what permissions the Author has that are breaking the Access rules in BuddyPress Docs.
I’m look to find that now.

• This reply was modified 3 years, 9 months ago by paulallison.

Hi @paulallison, It sounds to me like another plugin is filtering your permissions because BP Docs doesn’t differentiate between the Author, Contributor, or Subscriber WP roles. Any logged-in user has basic Docs capabilities, and BP admins have admin capabilities. So I’d be looking at your plugins to see what is changing the behavior. To check, deactivate all plugins except BP and BP Docs to be sure that the access protection works, then add plugins one at a time until it breaks.

• This reply was modified 3 years, 8 months ago by David Cavins.

We finally found the permissions that had to be turned off, thanks to your help here. THANK YOU!

Hi @paulallison If you can say with more detail how you resolved the issue that will help us and potentially future users of BP Docs. Thanks!