CiviCRM Community Forums (archive)

I did, thanks

Please review the updated docs @ http://wiki.civicrm.org/confluence/display/CRMDOC/checkUploadsAreNotAccessible

There are instructions there for identifying if you are seeing a "false positive" (CiviCRM shows a warning when files *are* in fact protected) OR if you are seeing a legitimate warning.

One possibility is that .htaccess rules might be bypassed for the server's IP address - so the request from your server IP is specially treated. That MIGHT cause a false positive. Or there might just be a bug in the check. If so, we'd like to find out what it is ...

Thanks for posting, Michael23, I appreciate your support! The two directories that I get the messages about are publicly inaccessible.  I have confirmed with my hosting company (vidahost.com) that .htaccess files at the directory level are supported.
Hence I have created  http://issues.civicrm.org/jira/browse/CRM-14210 If there's anything I can do to help debug this, just let me know - I'll do what I can.  FYI, at another hosting site I use - ukfast.com - this problem doesn't exist.  Isn't software just wonderful?

Hi Chris,

A quick look at my server logs reveals the following (in order of latest entry):

/media/civicrm/upload//latest-version-cache.txt 0 2/14/14 8:14 PM PHP/5.3.28
/media/civicrm/upload//latest-version-cache.txt 0 2/14/14 8:14 PM PHP/5.3.28
/media/civicrm/upload//latest-version-cache.txt 0 2/14/14 8:14 PM PHP/5.3.28
/media/civicrm/ConfigAndLog/CiviCRM.68195fa08526034ba3f485163397bafc.log 0 2/14/14 8:14 PM PHP/5.3.28

Hope that helps?

See http://issues.civicrm.org/jira/browse/CRM-14210 for a patch - thanks Andy for getting this onto the radar and giving us access to debug it.

On 4.4.5 (previously running 4.3.7) my contact images no longer load, giving me a 403 access forbidden error. If I delete the .htaccess that is in the /sites/default/files/civicrm/custom directory I am able to view my contact images again. The .htaccess says this:

<Files "*">
  Order allow,deny
  Deny from all
</Files>


@dotsam, that .htaccess change might permit sites to expose contact images again

This is a change in CiviCRM's default behaviour, but I'd argue it's an improvement even though we've had to change systems for one or two client sites on account of it.

CiviCRM deals with contact data for a wide variety of organisations; whether contact data including their image is for public or private consumption is not a given. I think the right thing to do is to protect data by default. For reference, the settings help for the contact image field @ civicrm/admin/setting/path says somethng like,

Path for storing the documents and images attached to the records of contacts (photos, resumes, contracts, etc.). These files are defined using custom fields of type "file".

That doesn't sound like public data to me.

Ultimately, I'd like to see CiviCRM head towards being able to define "public" or "private" per custom file field, as is possible with Drupal. That would make it much clearer and allow sites to handle this with greater flexibility.

If the web server is nginx, then you might add a configuration like this (untested - b/c I don't have nginx installed):

Code: [Select]

  location ~ ^/sites/.*/files/civicrm/(ConfigAndLog|upload|templates_c) {
    deny all;
  }


Since there will be other NginX users out there wondering about this, I've tested this on a Drupal 7.28 install with CiviCRM 4.4.5 on an Ubuntu server and can confirm that it does work - I just added it to the end of the NginX site configuration file located in the available sites folder. Also as per the changes in 4.4.5 I added the 'custom' folder as well, so the code looked like:
    location ~ ^/sites/.*/files/civicrm/(ConfigAndLog|upload|templates_c|custom) {
deny all;
    }
Thanks to Totten for the original info!

Is it not possible for the installation/upgrade script to install a structure that doesn't, by default, trigger security error messages?

No, and you probably don't want that.

CiviCRM (an application) should not be able to manipulate settings in the application's hosting environment. If it did, then CiviCRM (or Wordpress, or phpbb2, or ...) can likely hijack other sites on the same server, and so forth.

By making the server configurations writable to the webserver user, one might achieve this ... but it would be a far worse situation than the one where you need an administrator to configure your hosting environment properly. Your website (and others hosted on the same setup) would be pretty smartly eliminated, or put to nefarious work, or ...

EDIT: Where CiviCRM can write .htaccess files, AND Apache permits those access files to overwrite a limited amount of configuration, this is what's happening. Nginx have made an architectural decision not to do that, which means no .htaccess for Nginx users (for performance and other reasons documented on their site).

Regardless of the hosting environment, CiviCRM sites dealing with peoples private data require the skills (legal, technical, ...) to handle that data. (We understand that most NGOs are not massively cashed up, but they still need to be responsible!)