Lightweight cron functionality exposed to anon users? [#1463378]

Comment	File	Size	Author
#8	_1463378_8.scheduler.lightweight_cron_access.patch	525 bytes	jonathan1055
#2	_1463378_2.scheduler.lightweight_cron_access.patch	947 bytes	jonathan1055
	drupal-scheduler_cron_access-1.patch	536 bytes	cntlscrut

Comment #1

jonathan1055 commented 2 March 2012 at 17:29

Hello,
Yes you are right, anon users can run the scheduler lightweight cron and I'm sure that is not intentional. I'll test the patch. The same fault is in the D6 version, so we should fix both.
Thanks for spotting this!
Jonathan

Log in or register to post comments

Comment #2

jonathan1055 commented 2 March 2012 at 18:03

Status:

Active

» Needs review

Status	File	Size
new	_1463378_2.scheduler.lightweight_cron_access.patch	947 bytes

Just tested the patch, and you fixed the access to /admin/config/content/scheduler/cron
But running the cron via /scheduler/cron also needs to be fixed. The attached patch does both.

Log in or register to post comments

Comment #3

cntlscrut commented 12 March 2012 at 07:06

That looks good. The only reason that i didn't remove the callback for "/scheduler/cron" was because i saw the use of being able to add a call to that in the crontab that wouldn't call the full drupal cron functionality if it wasn't necessary.

My main issue was just with the admin functionality of being able to trigger the run via a button being exposed to anon users.
Though the liteweight cron is nice though, the drupal cron is already set and tested as secure and even in larger instances shouldn't pose a significant performance risk.

Looking at and testing the patch I don't see any major reason not to commit and tag a new release.

Log in or register to post comments

Comment #4

jonathan1055 commented 12 March 2012 at 19:49

Looking at #431776: Cron should run as anonymous when invoked via the run-cron link on the status report page and #793590: Switch to the anonymous user when running cron it seems that cron jobs should be executed as an anonymous user, and you were right not to remove the 'access callback' => TRUE from /scheduler/cron/

Hence the patch to be applied is the original at the top of this issue, not my patch in #2. Does anyone else want to confirm my understanding of this, and then mark it RTBC?

Jonathan