CiviCRM Community Forums (archive)

I don't think there is. The closest things that come to mind:
 - The REST variant of the API can accept user credentials.
 - CRM_Utils_System_*::getLoginURL($destination)

However, just to make sure I understand the situation correctly:

 - You're integrating with an external service by defining a callback on a CiviCRM site.
 - The external service specifies a particular request/response format (e.g. it POSTs an XML document and expects a certain XML document in response)
 - The external service knows nothing about Civi user accounts, Drupal login pages, Joomla login pages, etc.
 - The functionality of the callback is sensitive -- it shouldn't be open to the public.

Assuming this is correct, then a few general designs that come to mind:

 1. You could design your own mechanism which doesn't rely on the CMS user ID. For example, generate a random code and store it in the settings system. When a page-request comes in, see if the random code was submitted and abort unwanted requests. From the CMS's perspective, it should be safe to allow anonymous users to access the page (because they won't know the random code).
 2. One could develop a mechanism that works with the current page-request pipeline (e.g. update CRM_Core_Invoke to check for HTTP Basic Auth headers or to check for "?authCmsUser=XYZ&authCmsPass=XYZ"; update the Menu XML to make this an optional feature enabled for only certain URLs).
 3. One could develop a mechanism based on a new page-request pipeline (e.g. $civicrm/extern/callback.php) which performs the on-demand login and then uses a hook or XML file to pass control to your extension's code.

If any of these are worth pursuing, then we can pick one and drill-down. (FWIW, I lean towards #1 or #3.)

I generally agree with lobo's point and hope that CMS authentication ultimately isn't needed for Joe's use-case. (If nothing else, the documentation & setup will be simpler if it doesn't have to deal with authentication.) However, Joe's post gave me a more nuanced perspective on this:

...in general we should move away from the extern and bin scripts (except for cli.php?)...

The way we've done "extern" and "bin" in the past is problematic (e.g. it's not adaptable to extensions, and it produces a lot of duplicated-but-inconsistent code). However, if we ultimately find a need for Joe's "authenticated web callbacks" use-case, then I think it's another exception. It would be important to craft the exception well. We obviously don't want to drop another one-off PHP script under "extern" or "bin".

As a demonstration of what I meant in #3, consider something like this:

// FILE: civicrm/extern/callback.php
// USAGE: http://.../civicrm/extern/callback.php?user=X&pass=Y&key=Z&q=civicrm/my/page
require_once '../civicrm.config.php';
require_once 'CRM/Core/Config.php';
$config = CRM_Core_Config::singleton();

CRM_Utils_System::authenticateScript(TRUE);
echo CRM_Core_Invoke::invoke(explode('/', $_REQUEST['q']));

Like bin/cli.php and extern/rest.php, it's a relatively generic front-controller that works for any extension or component and builds on top of an existing request router. Like our normal web pages, it doesn't follow API conventions (and can instead follow the specifications needed for the web-callback). Unlike our normal web pages, it provides a consistent wire-protocol for authentication that can be used with "authenticated web callbacks" on any CMS.

(Note: The example is simplified for discussion purposes and shouldn't be used as-is -- a credible implementation would take more work and confront more issues/details.)

To add a page to an extension in civix right now one executes:
$ civix generate:page Greeter civicrm/greeter
Could we substitue something for page, maybe callback, to implement the above in civix?

Joe gave me this link on IRC:

https://github.com/JMAConsulting/biz.jmaconsulting.mte/blob/master/CRM/Mte/Page/callback.php

based on my quick read of the mandrill api, this is similar to a paypal ipn request and can be kept as a public open url

For security reasons, they recommend using a secret key between the client and the server, which the extension can and should manage. This should work across all CMS'es

I'd vote to keep things simple and not complicate stuff.

lobo