[drupal-devel] [feature] introduce a "cron" user to fix various
cron related issues
robertDouglass
drupal-devel at drupal.org
Sun Aug 14 08:23:43 UTC 2005
Issue status update for
http://drupal.org/node/5380
Post a follow up:
http://drupal.org/project/comments/add/5380
Project: Drupal
Version: cvs
Component: user system
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: ax
Updated by: robertDouglass
Status: patch (code needs review)
Eric, that makes sense. Thanks for the explanation.
robertDouglass
Previous comments:
------------------------------------------------------------------------
Fri, 23 Jan 2004 23:33:00 +0000 : 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 ;)
------------------------------------------------------------------------
Wed, 11 Feb 2004 05:04:29 +0000 : 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.
------------------------------------------------------------------------
Mon, 27 Sep 2004 19:25:42 +0000 : 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.
------------------------------------------------------------------------
Fri, 01 Oct 2004 18:41:16 +0000 : 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?
------------------------------------------------------------------------
Fri, 01 Oct 2004 21:11:37 +0000 : 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.
------------------------------------------------------------------------
Sun, 13 Mar 2005 19:18:05 +0000 : 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.
------------------------------------------------------------------------
Sun, 13 Mar 2005 19:37:14 +0000 : 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'
------------------------------------------------------------------------
Sun, 13 Mar 2005 20:11:09 +0000 : killes at www.drop.org
'User ID '.$cron_uid.' does not exist' < == needs to be made
translatable.
Setting to active.
------------------------------------------------------------------------
Mon, 14 Mar 2005 05:56:17 +0000 : 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.
------------------------------------------------------------------------
Mon, 14 Mar 2005 09:48:51 +0000 : 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?
------------------------------------------------------------------------
Mon, 14 Mar 2005 13:11:44 +0000 : 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
------------------------------------------------------------------------
Mon, 14 Mar 2005 13:45:54 +0000 : javanaut
"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.
------------------------------------------------------------------------
Mon, 14 Mar 2005 19:08:48 +0000 : killes at www.drop.org
@Chris: I am pretty sue that this patch will not be usefull if the cron
user does not get a session. Drupal relies on the session to
authenticate the user. If you are worried about too many sessions, you
should make sure the session is clossed at the end of the run. his
could be done in cron.php.
@Stefan, Ber: I think we should introduce just a standard user and
assign the "authneticated user" role to him. The set the variable to
that uid so we can check which user it is. The problem is that we
cannot create the user from database.mysql beacuse the next uid would
be No. 1 which is reserved. So we would need to create the user on the
first visit to the admin/settings page. We could also use
drupal_set_message to inform the admin of this. We should also extent
the relevant help text.
While we are at it we could make the anon user use the db tabe for its
name too and not a variable.
------------------------------------------------------------------------
Mon, 14 Mar 2005 20:33:00 +0000 : Chris Johnson
Looks like we are sort of in a corner. Really the cron user should be
in the database at install time, but we have to reserve uid 1 for the
first user. Maybe there is another way to do that without having the
first entry to admin create the cron user? That seems hackish to me.
I agree that the anonymous user should also be completely coded into
the database, and not a variable. The current methods causes anomolous
behaviors. I, in fact, wrote several patches to do that a long time ago
(http://drupal.org/node/5639). I looked at updating that patch a couple
of months ago, but the new unregistered user comment capability where
the user can enter his name made the code a lot more complicated.
Maybe I will get motivated to try it again. If only my patch had been
applied the first time! :-)
------------------------------------------------------------------------
Mon, 14 Mar 2005 21:21:12 +0000 : Olen
How about creating a bunch of "reserved" users (like most linux
distributions do)?
uid 1 = root
uid 2 = cron
uid 3 - 8 = reserved for later use
uid 9 = anonymous
And then let the admin log in as root the first time. We still let
him/her change the username of any of these users, so it should not
cause to many problems for new installations. Older ones would either
just have to live with it, or do a lot of 'UPDATE module_table SET
uid=X WHERE uid=2'-queries.
------------------------------------------------------------------------
Mon, 14 Mar 2005 22:33:32 +0000 : Bèr Kessels
What about following the linux thing, and start counting at 500 for
normal users? That way people will recognise it, and numbers do not
matter anyway. I mean, there is really no difference between 4 and 500,
other than thats its a different number. 500 makes just as much sense as
10, or 2 or 4.
Bèr
------------------------------------------------------------------------
Tue, 15 Mar 2005 12:59:18 +0000 : Philippe
The reason why I created the "ugly" user interface, and let the site
admin choose a cron-user ID in the settings page is because of backward
compatibility with existing installations. (guess what: my site IS an
existing installation)
Perhaps another option is to give special users a user ID close to
2147483647 (MAXINT). That way it won't interfere with existing users.
------------------------------------------------------------------------
Thu, 16 Jun 2005 23:12:05 +0000 : degerrit
At the risk of being publicly humiliated, and in the spirit of "there's
no such thing as a stupid question" ... what exactly is the (security?)
issue with adding:
$user = user_load(array('uid' => 1));
in cron.php? I have two sites with node_privacy_by_role (NPBR) enabled,
and cron does not index all the pages as a consequence (except when it
is given a user id with full access like above). It took me some
puzzling to figure out why the sites seemed stuck at "11% of the site
has been indexed" or something similar.
Of course, now a non-authenticated user can see excerpts of "private"
pages through the search, which could be a big deal.
Anyway, being able to choose a search user would solve the problem with
NPBR as well it seems.
------------------------------------------------------------------------
Fri, 12 Aug 2005 15:59:10 +0000 : robertDouglass
Why do we need a user besides uid=0 for cron? Just because the project
module writes anonymous on certain closed issues? If cron runs with
uid=0 most of the time anyway, why don't we just hardcode that in
instead of creating a new type of user?
------------------------------------------------------------------------
Sun, 14 Aug 2005 07:57:09 +0000 : ejort
@robertDouglass: Why do we need a user besides uid=0 for cron?
There are genuine use cases for cron running with greater permissions
than those provided by uid=0, and having a specific cron user allows
the administrator to determine exactly which permissions the cron user
gets.
For instance I just spent half a day figuring out why my simplenews
installation was mailing multiple empty messages to subscribers plus 1
working message. My simplenews mail messages are only accessible by
users with the 'authenticated user' role via taxonomy_access, my
simplenews install sends for 20 seconds on message submit and then
continues sending later via cron. When sending via cron the message
body couldn't be accessed by the anonymous user and so an empty message
got sent. It was only when a logged in user initiated a send run that a
proper message was sent. Without the ability to assign permissions to a
cron user, I have to allow access to my newsletters to anonymous users.
So, that's my +1 for this functionality.
@killes: . So we would need to create the user on the first visit to
the admin/settings page.
I agree that this variable ('cron_uid') should be set automatically
without requiring any admin intervention. Can't we create this user in
update.php? The variable defaults to 0 which is the current behaviour
in any case.
Finally, I think that the logic to not create a session for the cron
user should be removed from this patch. Instead we should destroy the
session at the end of the cron run.
Cheers,
Eric
More information about the drupal-devel
mailing list