[drupal-devel] [feature] introduce a "cron" user to fix various cron related issues
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: Bèr Kessels Status: patch 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 Bèr Kessels Previous comments: ------------------------------------------------------------------------ January 24, 2004 - 00: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 11, 2004 - 06: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 - 20: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 - 19: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 - 22: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 - 20: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 - 20:37 : killes@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 - 21:11 : killes@www.drop.org 'User ID '.$cron_uid.' does not exist' < == needs to be made translatable. Setting to active. ------------------------------------------------------------------------ March 14, 2005 - 06: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 - 10: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 - 14: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 ------------------------------------------------------------------------ March 14, 2005 - 14:45 : 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. ------------------------------------------------------------------------ March 14, 2005 - 20:08 : killes@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. ------------------------------------------------------------------------ March 14, 2005 - 21:33 : 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! :-) ------------------------------------------------------------------------ March 14, 2005 - 22:21 : 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.
On Monday 14 March 2005 17:33, Bèr Kessels wrote:
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.
Not a bad idea. The database purist in me wants to run screaming from this, because in a purely theoretical sense, having an "arbitrary" ID number begin to mean something breaks the contract of what an ID number is. That being said, this may be a case where practicality [rightly] wins over academic purity. :-) If this happens, it should be very clearly documented because not everyone who upgrades Drupal will use the automated scripts to do so. OTOH, if the uid field were to become signed, it might be reasonable to stipulate that any negative, nonzero uid number has full privileges. This opens the possibility for sites with shared technical administration, with the admins each having his/her own "root level" ID, but the logs still show with more granularity who did what. Better than sharing a single password. Doesn't require reassignment of any existing UIDs from previous versions, except for the root user itself which goes from +1 to -1. Theoretically that specific constant value should only be seen within core code, not contribs (yes, I know that's an ideal assumption, but probably mostly valid). While we're on the subject of uid numbers, may I offer an additional suggestion? Make uid=0 the anonymous user, and allow it to have "preferences" like any other user, except that only people with "administer users" privilege can set those preferences. Advantages: * Some things that now have one mechanism (variable table) to set system-wide defaults, and someplace else (user profile) to set user-specific overrides would save code complexity, because they just do two user-profile lookups where one happens to be uid=0 instead of uid=$user->uid. * Empty returns from database queries are treated numerically as zero in many PHP functions, so this change is unlikely to break existing code that relies on things like "if ($user->uid) {...". In other words, having $user exist but have a uid of zero for anonymous sessions now becomes a possibility. * Modules could rely on $user object always being present, and that object could be created even before authentication is known then populated more extensively later. Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey
Scott Courtney wrote:
Make uid=0 the anonymous user, and allow it to have "preferences" like any other user, except that only people with "administer users" privilege can set those preferences.
That was part of what I tried to do here: http://drupal.org/node/5639 Unfortuantely, the patch languished in the patch queue until progress made it no longer even close to applying. Specifically, the work to allow anonymous posters to enter their names really complicated the issue. But it should still be fixed. -- Chris Johnson
participants (3)
-
Bèr Kessels -
Chris Johnson -
Scott Courtney