Remove CiviCRM entry points except via CMS frontend

[torrance123]

I'm currently working on the Drupal 8 port, and one of the pain points I'm encountering might be relatively easy to fix.

At the moment there are two main entry points into CiviCRM — one is via the CMS which initializes CiviCRM, and the other is by directly calling a CiviCRM php file. In the latter case, it will sometimes be necessary to bootstrap the CMS to do user validation checks, etc. In CRM/Utils/System/{CMS}.php there's a fair bit of really quite ugly code handling this alternative, back-to-front bootstrapping. It seems to me that settling on a single code path would result in more reliable and better tested code.

My proposal is to ensure the only entry point into CiviCRM is by way of the CMS, ie. the CMS will already be bootstrapped. Alternatively, leave the 'naked' php files in CiviCRM as they are but change those that require the CMS to be bootstrapped to go in via the CMS first.

I presume the reason for the naked PHP files is performance, but things like cron, migrations, etc. aren't so time critical that an extra ~300ms of CMS bootstrapping up front is going to cause issues. And at least in Drupal 8, bootstrapping the system is much less expensive now thanks to lazy loading much of the system — especially if CiviCRM could let the CMS know ahead of time (ie. as a flag in the civicrm_menu table) when a request is  full HTML response or whether its simply json/xml/etc.

From a brief bit of grepping, the files that require bootstrapping the CMS or authenticated against the CMS are:

• bin/cli.class.php
• bin/cleanup42
• bin/ContributionProcessor.php
• lots in bin/deprecated/%
• bin/encryptDB.php
• bin/migrate/export.php
• bin/migrate/exportJSON.php
• bin/migrate/import.php
• bin/migrate/importJSON.php
• bin/migrate/move.php
• CRM/Utils/SoapServer

I'm curious to know how people feel about this, and in particular whether this would make other CMS maintainer's (eg. WP, J!) lives easier too.

[totten]

Generally, +1. Fewer entry-points makes implementation easier for multiple CMS's. Running requests through the CMS's normal web-request-router also ensures more consistency (eg the same hooks will always fire).

However, I think we can cut-down on entry points via consolidation. You see this in bin/deprecated vs bin/cli.php and extern/rest.php -- there used to be several standalone scripts (which are now deprecated), and you used to call them via CLI or web UI. Now we've moved that logic into APIs, and we only need two entry-points (bin/cli.php and extern/rest.php).

I think there should be a total of 2 or 3 entry-points:

1. CMS (Web-Based) Entry Point
2. CLI Entry Point (eg bin/cli.php). This currently focuses on API, but it could be extended using Symfony Console to be a bit more comprehensive. (It would be great to have something like "drush scr" or "drush eval" which runs on any CMS.)
3. (Arguable) Callback Entry Point (eg bin/callback.php) -- which bootstraps Civi (but not CMS). This is useful for functionality like extern/open.php and extern/url.php (which are time-sensitive and impact our statistics-collection).

[jcasharpe]

+1 for minimising entry points. In my nginx deployment I heavily restrict what files can be run under php to minimise risk. The fewer number of files I need to list the better (and when I initially implemented this a number of things kind of broke silently because I hadn't whitelisted all the extern/*php scripts).

[Sean Madsen]

I started a new thread asking: how do I whitelist these extern/*php scripts? Note that this new thread is specific to the perusio/drupal-with-nginx configuration, but jcasharpe, you might be able to help here.