Запуск hook_cron с правами администратора в Drupal 6 - PullRequest
2 голосов
/ 06 августа 2009

Есть ли способ разрешить hook_cron работать с правами администратора - например, как бы sudo hook_cron()?

Этот вопрос является продолжением моего более раннего вопроса , пытающегося диагностировать, почему функции hook_cron (), вызываемые /drupal/cron.php, работают иначе, чем те же функции, вызываемые /admin/reports/status/run-cron.

Моя конкретная функция (назовите ее foo_cron()) обновляет профили пользователей в рамках своих ночных обязанностей. Но /drupal/cron.php, очевидно, работает как анонимный пользователь. Анонимные пользователи не могут изменять поля профиля пользователя на этом сайте по понятным причинам, поэтому эта часть скрипта завершается ошибкой.

Я знаю, что могу обойти эту проблему, изменив profile_fields напрямую, используя SQL, но это похоже на уродливый хак, и его будет сложно поддерживать, если я начну делать это в нескольких модулях.

Является ли способ, в рамках существующих функций и инфраструктуры Drupal, запускать определенные задания foo_cron () с привилегиями, которые мы обычно предоставляем только администраторам, например, обновление профилей?

Этот конкретный сайт работает под Drupal 6.1.3.

Ответы [ 2 ]

2 голосов
/ 28 июня 2010

С Страница справочника drupal cron : Запуск cron в качестве аутентифицированного пользователя

#!/bin/sh
# Reference http://drupal.org/node/479948#comment-1673488 by pearlbear

SITE=https://dev.example.com/
USERNAME=user.name
PASS=ChangeMe!!12

COOKIES=/tmp/cron-cookies.txt
WGETPARAMS="--quiet -O /dev/null --no-check-certificate --save-cookies $COOKIES --keep-session-cookies --load-cookies $COOKIES"
# if you run drupal in a default language different than English you need to modify this
LOGIN="Log%20in"

wget $WGETPARAMS "${SITE}user"
wget $WGETPARAMS --post-data="name=$USERNAME&pass=$PASS&op=$LOGIN&form_id=user_login" "${SITE}user"
wget $WGETPARAMS " ${SITE}cron.php"
1 голос
/ 07 августа 2009

Все, что вам нужно сделать, это сохранить глобальную переменную $ user, затем изменить $ user global на пользователя с таким разрешением, а затем снова изменить пользователя.

Теперь я бы не рекомендовал это, но предложил бы вместо этого использовать SQL, поскольку этот подход очень хакерский и немного небезопасный для запуска заданий cron с правами администратора.

...