Having 'fixed' cron keys for each Drupal installation is kind of limitation. If for any reason is required to change the default cron key generated by Drupal, the admin should be able to generate a new one. The patch adds this feature.
See screen shots attached.
EDIT: There's a module for this: Cron key.
| Comment | File | Size | Author |
|---|---|---|---|
| new_key_generated_msg.png | 4.18 KB | dropcube | |
| new_cron_key_status_report.png | 20.94 KB | dropcube | |
| cron_generate_key.patch | 2.73 KB | dropcube |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #1
Susurrus commentedI really vote against this as it's more code and more user interface for very little gain. This discussion existed in the original issue to add the cron_key and it wasn't added originally. There are practically no reasons to change the cron_key first of all. If it needs to be changed, it's a simple SQL query that can be run in a db_query() somewhere in a custom PHP input field or through the DB backend that. If we were to do anything about this, I would vote to add a code snippet to that area of the handbooks.
Comment #2
dropcube commentedThere are no more than 12 lines of new code. My intention is to avoid the crontib module cron_keys-7.x-x-x that for sure will appear in the future.
Comment #3
lilou commented-1 unnecessary in core.
Comment #4
amonteroHow about checking if cron key present in the 'Status report' page?
I see 2 possible use cases for this:
1. Something went bad in db/config (the obvious case). It would be nice to alert the site owner of such problem. Sh** happens and this can be tricky to troubleshoot.
2. Site is a local/staging/developer db dump and has been sanitized by removing cron_key var. Since cron_key seems a value to protect, it's not that strange to do it.
2nd case is what I'm now doing manually now, but devs should be aware fo it. Making Drupal a bit more self-healing here would allow an easier workflow here.
Additionally, an easy hook_drush_sql_sync_sanitize implementation could be added to drush to automate this for "drush sql-sync --sanitize" invocations. I think this use case is worth accounting for, specially for dev workflows meant to be secure. Disclosing the cron_key for each db dump may not be always desirable.
Optionally, the error message in the status page could let the site owner to regenerate it by clicking a 'generate now' link. I'm not talking of generating new cron_key at will, but regenerate it if missing.
I'm already aware that this should be first implemented in 8.x, but I still think it's a feature worth having also in 7.x.
What do you think?
Comment #5
amonteroComment #6
marcingy commentedThis was closed in 2008 it is simply not needed in core
Comment #7
amonteroHi marcingy.
What would be the problem in having such thing in core? Can you elaborate on this, please?
Maybe I should open a new issue? I searched first and since found this closely similar, thought it would be better to not spawn a new issue.
TIA.
Comment #8
amonteroReopening for further input.
As an added use case, how about cron key being compromised?
Comment #9
amonteroTagging 'security' to attract review in case of cron_key compromise.
Comment #10
amonteroCategorizing.
Comment #11
amonteroAdding https://drupal.org/project/cron_key module to OP.
Comment #12
christefano commentedThanks for pointing me to this issue, amontero. I agree this should be in Drupal core and will review this and related issues when I have a free moment.
Comment #13
gregglesRemoving the tags. Cron is a component so no need to tag with it.
I'm not sure I see how this is security related, so removing that. Can you expand on that?
Comment #15
gregglesThe menu callback needs some protection against CSRF.
Comment #16
nevergoneDrupal 7 & Drupal 8: https://www.drupal.org/project/cronkeychange
Comment #17
tstoecklerIf for example the cron key to a site was in some way accidentally publically disclosed and is now actively being used to DoS the site, I would consider it a security improvement to be able to change the key in an easy way. So I think the "security" tag (or "Security Improvement") is warranted. But maybe I'm missing something.
Comment #18
nevergone#17:
1.) disable outside cron url (htaccess or other alternative)
2.) use drush
3.) PROFIT! :)
Comment #19
gregglesOK, I can see that. Security improvements is the main tag used for security related items in the public queue.
Comment #20
christefano commented@nevergone, the Cron Key module does this, too. Would you like to combine forces or obsolete one of our modules? My preference would be to EOL mine as you already have a D8 version.
https://www.drupal.org/project/cron_key
Comment #22
oturpin commentedHello,
I am using Elysia cron. Is this module compatible with it ? I cannot see the "change key" interface on parameter page ?
Thx
Comment #27
joachim namysloMaybe it is easier to bring this into core
https://www.drupal.org/project/cronkeychange