Problem/Motivation

I've been trying to help get CiviCRM working with Drupal 8 (namely on CRM-17652 in the CiviCRM's JIRA), and encountered an issue with the vendor/.htaccess blocking CSS/JS assets from CiviCRM.

So, first a quick overview of how CiviCRM integrates with Drupal 8:

  • CiviCRM has two parts: a library part (same for any CMS) and a Drupal module (for integrating with Drupal). CiviCRM can also work inside of Wordpress, Joomla, etc
  • CiviCRM is based on Symfony and has some other composer dependencies, so in Drupal 8, the library part needs to be installed via composer, and so it gets placed in vendor/civicrm/civicrm-core
  • CiviCRM is really more like an application than a most libraries installed via composer, and so rather than having just PHP code, it also has CSS and Javascript assets. It has these assets because it can work with several CMS's and needs the same assets, so they aren't in the Drupal module, which would be more the Drupal way

The problem is that vendor/.htaccess blocks access to any of the CSS and JS assets via the web-browser.

The vendor/.htacess is created by Drupal\Core\Composer\Composer::ensureHtaccess, which was added in #2508591: vendor/ is web accessible, primary to block accessing arbitrary PHP files via the web browser for security, but I could also see accessing arbitrary Javascript files to be a security issue.

Now, CiviCRM is a pretty unique case. So, I could see the argument that fixing this is up to the Drupal site admin: she could remove the 'scripts' line in composer.json, and re-write the vendor/.htaccess to exempt CiviCRM. But, since CiviCRM is great and shares a long history and collaboration with the Drupal community, it'd be kinda nice to support it out-of-the-box :-)

What are the options to fix this?

This also has implications for #1672986: Option to have all php files outside of web root.. Whatever process is established there would need to accommodate composer dependencies that have assets too.

Proposed resolution

No proposal yet. We need something that balances security with ease of use.

Remaining tasks

  1. Discuss
  2. Decide on solution
  3. Implement

User interface changes

None.

API changes

None.

Data model changes

None.

Comments

dsnopek created an issue. See original summary.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented

As a possible solution from the CiviCRM end, I found this composer plugin:

https://github.com/atelierspierrot/assets-manager

... which allows making "asset packages" that get installed outside the vendor directory. So, one idea is that maybe CiviCRM could put it's assets in a separate asset package?

Still open to other ideas! :-)

cilefen’s picture

cilefen commented

You could perhaps split the assets into a separate repo and use composer/installers with the drupal-library type.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented

Hm. I don't think it could be "type": "drupal-library" because civicrm-core would need to depend on it, and civicrm-core can be used in Wordpress, Joomla, Backdrop, etc. But, yeah, another repo which got installed to an alternate path would work...

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

fathershawn’s picture

fathershawn
Primary language English
Location New York
commented

@dsnopek With regard to #4 and cross-cms complexity - what if CiviCRM adds a composer.json to the Drupal compatibility module which has the dependencies to CiviCRM core and assets projects? The other CMS could have stub composer projects also that are not much more than composer.json to any cms specific dependencies that they had as well. Then installing civi is done via 

composer require civicrm/[cms]

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented
Status: Active » Closed (works as designed)

FYI, I "solved" this with CiviCRM by having a build process that copies all of the CSS/JS assets under WEBROOT/libraries/civicrm. I'm not currently doing this as a composer post-install-cmd/post-update-cmd script, but I think that's probably the right way to do it and CiviCRM could bundle a PHP class to use in those scripts for exactly this purpose.

CiviCRM has a useful settings variable for the "Resource URL" that allows pointing to an arbitrary location for the assets which allows this to actually work. I suppose I could imagine other PHP libraries that want to access their assets with the assumption that the vendor directory is web accessible and NOT provide some kind of setting variable to find those assets, but I think that's probably a bug in that library.

I'm gonna close this issue for now, but someone encounters a similar situation with a different library and wants to continue the discussion, please feel free to re-open!