CiviCRM intentionally doesn't provide login functionality for the CMS. Access bypass could have serious implications for your org - use with caution. You don't want to wake up in the newspaper because your membership DB got disclosed.
Similarly, CiviCRM emails aren't treated the same way that password reset emails are. People forward CiviCRM emails a lot, and if you're providing login functionality you risk exposing user information when doing so.
Use the examples below with care.
If you want to use CiviCRM checksums to implement the same functionality as a Drupal login, you could do the following perhaps?
- Create a custom extension which provides a custom menu callback (eg
civicrm/user-login).
- In your custom callback, identify the Drupal user and log them in. (This is really easy.
- Send out an email with a CiviCRM checksum pointed at this callback and perhaps with an additional parameter indicating the final destination URL.
- Perhaps add some checks to prevent it working for any users with "administer site configuration" permissions to limit the chance of abuse.
You have code to validate a checksum above, so from here you'd want to -
Identify the user to match
$params = array(
'version' => 3,
'sequential' => 1,
'contact_id' => 1,
);
$result = civicrm_api('UFMatch', 'get', $params);
// $uid is $result['values'][0]['uf_id'] or similar here.
Load the matching user
$account = user_load($uid);
Check they aren't an admin (fairly arbitrary this)
if (!user_access('administer site configuration', $account)) {
// ...
}
Log them in
global $user;
$user = $account;
CiviCRM provides multiple concurrent checksums, since a user may have received one of several emails recently. Drupal provides only a single user login URL at a time.
It is possible to add Drupal login URLs to an email, and you could do this by implementing your own custom token, BUT you'd have to play along with Drupal's login lifespan (24 or 48H?) and any other limitations. CiviCRM checksums will be easier to handle here, provided you can account for the security implications of doing this :)
