Support » Plugin: BuddyPress Docs » allowoverride problems

  • Resolved havealookhere

    (@havealookhere)


    Hello,

    I moved my website to Siteground. All is okay exept this error message:

    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.

    So I went to the wiki and that tells me:

    Doc Attachments inherit the privacy levels of the Docs that they are attached to. This works by redirecting the normal WordPress attachment links to a special script that checks for a user’s capability before delivering the file.

    BuddyPress Docs attempts to take additional steps to ensure that your Docs cannot be accessed directly by those who might guess the URLs. Depending on your server setup, you may have to take some additional manual steps to ensure 100% attachment privacy.

    Apache
    On Apache installations, BuddyPress Docs attempts to protect attachments on a doc-by-doc basis. This means that attachments to private Docs will be served through BuddyPress – ensuring proper authorization – while attachments to public Docs will be served directly by Apache – ensuring the lowest possible overhead.

    In order for BuddyPress Docs to protect attachments in this way, AllowOverride must allow for subdirectory-specific rewrites. The vast majority of WP installations will have this setting enabled by default. Contact your host for details. For more information, see Apache’s documentation for AllowOverride.

    But to be honest, i dont have a clue what to do ?

    So i have asked my hoster, but they say then cannot give me an advice about htaccess rules. And said i have to ask the buddypress docs people.

    Can someone please explain to me what Rule i have to use?

    On siteground they say this about allowoverride : The AllowOverride directive in the Apache’s configuration has been set to ‘All’ on all servers.

    Any help is really appreciated.

    Warm regards

    Jap

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Author David Cavins

    (@dcavins)

    Hi @havealookhere, I’m not familiar with SiteGround but I’m told they have good support. You can test if the BP Docs attachment protection is working by attaching a file to a private BP Doc. Then, copy the attachment url, and in a browser in which you are not logged in to the site, attempt to load that attachment via the url. If you can see the attachment, then BP Docs is not able to write the htaccess rules as needed. If you can browse the site files, visit /wp-content/uploads/bp-attachments/{whatever your new docs's ID is} and see if there is a hidden file, .htaccess in that directory. If the doc is private, the htaccess file will contain:

    # BEGIN BuddyPress Docs
    RewriteEngine On
    RewriteBase /
    RewriteRule (.+) ?bp-attachment=$1 [R=302,NC]
    # END BuddyPress Docs

    Best,

    -David

    Plugin Author David Cavins

    (@dcavins)

    Hi @havealookhere,

    Did you ever resolve this issue? What was the problem?

    Best,

    -David

    Thread Starter havealookhere

    (@havealookhere)

    HI,

    No, it was caused by the nginx fast delivery service of siteground.. I have switched it of and then it worked again.

    I am sorry, i did not give a reply to your comment.I was very busy with a lot of things.

    In the near future i will go into this problem again, but now its not at the top of my to do list.

    regards

    Jap

    Plugin Author David Cavins

    (@dcavins)

    Thanks for the update!

    I also have this issue, but with Cloudways (who also run apache and nginx) Attachments are visible on private documents when viewed through an incognito window. The AllowOverride is on for the apache server

    I think this might be something you want to explore David, as if nginx fast service delivery is being used by hosts to deliver websites quickly, you don’t want your plugin to impact site speed because it has to be turned off.

    I have let Cloudways tech support know and I’m awaiting their response regarding the impact on site speed.

    Thread Starter havealookhere

    (@havealookhere)

    at siteground they couldnt change this behaviour.. the tech support tried it, but could only give me the advice to switch nginx off.

    Cloudways tech support is going to have a look. If they solve it, I’ll let you know what they did.

    Plugin Author David Cavins

    (@dcavins)

    Hi all, you can read more about BP Docs’ support for nginx here: https://github.com/boonebgorges/buddypress-docs/wiki/Attachment-Privacy#nginx

    Best,

    -David

    @edroundtables Were you able to get this resolved and/or receive a reply from Cloudways?

    I ask because I am dealing with the same issue on a Cloudways server (Digital Ocean) and this is the reply I received:

    Thanks for reaching out to us. The directive for AllowOverride is already used and enabled on apache server and the following code is already added to Apache configuration:
    Options -Indexes -Includes -ExecCGI +FollowSymLinks
    DirectoryIndex index.php default.php index.html default.html
    AllowOverride All
    Require all granted

    If there are some permission issues on the application or any special permission which we have to use for your BuddyPress plugin you can share with us so we can change the permissions as your WordPress multisite is currently using standard set of permission.

    I am curious if this issue is related to nginx as @havealookhere mentioned? That will be my next question to Cloudways support.

    I got the same answer as you did. They did make some changes to the nginx server but ended up blocking access to the attachments entirely. I am looking at alternative options at the moment. I am reluctant to do anything that would impact the site speed in the future, and then for me not to remember what changes were made to the server and what to undo.

    If they manage to come up with a solution let me know.

    @edroundtables Thanks for the quick reply, and I will post here if a solution is found.

    @edroundtables I will spare you the details, but after a week I was finally able to convince/prove to Cloudways support that this issue was caused by the server configuration.

    Here is the reply they gave me; I would think you could contact them again, reference the issue and this thread, and let them know what was done in my case.

    The issue was with Nginx. In our stack, Nginx is working as a reverse proxy for Apache and the plugin you are using is used for static content. Nginx is serving the content before the request reaches to Apache. Now its working fine when we force the content is processed through Apache.

    Plugin Author David Cavins

    (@dcavins)

    @kuznacic, Thanks for the update! The setup they’re describing would be fine for a static site, but a membership-based site requires something else.

    Thanks for sharing your solution.

    -David

Viewing 13 replies - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.