[drupal-devel] [feature] introduce a "cron" user to fix various
cron related issues
javanaut
drupal-devel at drupal.org
Mon Mar 14 13:45:59 UTC 2005
Issue status update for http://drupal.org/node/5380
Project: Drupal
Version: cvs
Component: user system
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: ax
Updated by: javanaut
Status: patch
"Make a new user in the db called 'Cron' with a user id -1"
Just on a technical note, the database type for uids is "unsigned" and
-1 won't work.
javanaut
Previous comments:
------------------------------------------------------------------------
January 23, 2004 - 17:33 : ax
we currently have some problems caused by the undefined state of $user
in the cause of cron runs. sometimes it's "Anonymous", sometimes it
picks up the currently logged in user (i think). I stumbled upon this
when reading issues closed by "Anonymous" caused by the automatic cron
closure when issues are fixed. i always think "isn't it strange that
"Anonymous" can close issues just as she feels like?" there are quite
some related issues - search this site for "cron user".
couldn't a cron user solve these problems? a la if (REQUEST_URI) ==
cron.php then $user = <cron_user>, with <cron_user> having some special
properties such as showing "Automatically" for closed issues, being
possible to excluded in statistics, putting the rss author from
imported rss nodes into nodes author field, having special access
checks etc.
i didn't think about this much, but thought it is worth filing here.
please discuss, elaborate - and don't flame me if i'm too off ;)
------------------------------------------------------------------------
February 10, 2004 - 23:04 : Chris Johnson
Sounds like a good idea to me. It's one of many things I'd like to
change if I get time to work on it.
------------------------------------------------------------------------
September 27, 2004 - 13:25 : Philippe
Couln't we just write this in cron.php:
<?php
$cronuser = variable_get('cron_cronuser','nobody');
if ($cronuser = 'nobody'){
$user = user_load(array()); //I believe this results in Anonymous??
}else{
$user = user_load(array('name' => $cronuser));
}
?>
We can set the variable cron_cronuser in a page like admin/cron. If the
site administrator doesn't set a value, cron uses Anonymous for
everything (not some user that happens to be logged on). If a valid
user name is set, the site admin can give the cron user special
privileges.
------------------------------------------------------------------------
October 1, 2004 - 12:41 : Philippe
Setting the user like this in cron.php sends a cookie. (How? Where? Can
we prevent this?) So everybody can get "cron" privileges by loading
cron.php once. We could fix this by making cron.php accessible only
from localhost (in .htaccess).
Any ideas?
------------------------------------------------------------------------
October 1, 2004 - 15:11 : Philippe
Attachment: http://drupal.org/files/issues/cron_uid.patch (3.62 KB)
This patch lets the admin select a UID for cron in the admin/settings
page. The variable name in which this is stored is 'cron_uid'. When
cron.php is loaded, it sets a variable $cron_is_running. If this
variable is set, no session will be opened (and no cookies will be
sent). The cron page will use the Anonymous user (uid==0) if cron_uid
is not set.
Note that the site admin should create a "cron" user before setting the
UID.
------------------------------------------------------------------------
March 13, 2005 - 13:18 : Chris Johnson
Attachment: http://drupal.org/files/issues/cron_uid2.patch (3.19 KB)
Previous patch still applies cleanly to HEAD and code algorith looks
good on inspection. However, there are some style problems and one
ugly bit using StdClass(), so I have re-rolled the patch.
------------------------------------------------------------------------
March 13, 2005 - 13:37 : killes at www.drop.org
I like the idea, some comments, though:
+if (!$cron_is_running) {
+ session_start();
+}
Is this neccessary?
'User ID '.$cron_uid.' does not exist'
------------------------------------------------------------------------
March 13, 2005 - 14:11 : killes at www.drop.org
'User ID '.$cron_uid.' does not exist' < == needs to be made
translatable.
Setting to active.
------------------------------------------------------------------------
March 13, 2005 - 23:56 : Chris Johnson
Attachment: http://drupal.org/files/issues/cron_uid3.patch (3.29 KB)
Ooops. Sorry I missed that text that needed translating. New patch
attached with that bit corrected.
Yes, I think the if (!$cron_is_running) code is needed to keep the cron
user from creating many unneeded sessions.
------------------------------------------------------------------------
March 14, 2005 - 03:48 : stefan nagtegaal
I am all for the idea of introducing a special id for running the
cronjobs, but the approach you took here is far from perfect imo..
After looking at your patch, there are several questions and remarks
that came up to my mind:
I agree with Gerhard that the $cron_is_running is probably unneeded, I
think it's better todo:
<?php
if (!variable_get('cron_busy', true)) {
session_start();
}
?>
I think that this is much to technical. Severa newbies will probable
ask what a user id is, or what cron jobs are.. From both usability and
userfriendlyness this patch is a big -1 from me..
I would suggest todo the following:
- Make a new user in the db called 'Cron' with a user id -1, or
something like that.. That way you don't have to add extra options to
the administration, and the way of implementing should be much cleaner.
Also does it improves usability...
What do you think?
------------------------------------------------------------------------
March 14, 2005 - 07:11 : Anonymous
Hi,
The functionality is great, but your interface is not.
IMO you should just choose good defaults and leave it with that. Why
would users want to choose "UIDs" ofr "cron Jobs". Joe user should not
have to think about UIDs and Crons. IT should Just Work[tm].
I know there are lots of places in Drupal where this is not the case
either, but we are working on that.
So when we introduce new functionality we should do it good at once.
Why not go for Stefans suggestion of choosing a cron UID and jsut leave
it like that. UIDs are not really used anyway, so you can choose just
any UID (just the next one available, most often will be '2').
Bèr
More information about the drupal-devel
mailing list