Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Drush provides a feature called sql-sanitize that helps to delete data that shouldn't leave a production environment.
A drush file with these contents are all you should need.
function password_policy_drush_sql_sync_sanitize($site) {
drush_sql_register_post_sync_op('password_policy_history',
dt('Delete all history table entries (depending on the site config, may contain sensitive data).'),
"TRUNCATE password_policy_history;");
drush_sql_register_post_sync_op('password_policy_force_change',
dt('Delete all force change table entries (depending on the site config, may contain sensitive data).'),
"TRUNCATE password_policy_force_change;");
}
If there are other tables that webform stores data in, then please do add them in a similar fashion.
Comment | File | Size | Author |
---|---|---|---|
#6 | password_policy-7.x-2.x-add_drush_sql_sanitize_support-2555053-6.patch | 706 bytes | AohRveTPV |
Comments
Comment #2
AohRveTPV CreditAttribution: AohRveTPV commentedSQLite doesn't seem to have
TRUNCATE
orTRUNCATE TABLE
. Do you know ifDELETE FROM
would work just as well?I am interested in this feature as currently I have Bash script which sanitizes those tables using direct SQL.
Comment #3
gregglesSeems fine to me. Delete can be a little slower than a truncate, but speed is not likely to be critical.
Comment #4
AohRveTPV CreditAttribution: AohRveTPV commentedI think there might be a problem with this Drush feature. If the query is
DELETE FROM password_policy_history;
, the rows are deleted as expected when usingdrush sql-sanitize
. I assume that will not work when table prefixes are used and the--db-prefix
option is passed tosql-sanitize
, so I made the query insteadDELETE FROM {password_policy_history};
. However, with that query, if not using table prefixes, the rows are not deleted when usingdrush sql-sanitize
.I think table prefixes are less commonly used, but it would be insecure for the sanitize command to just not work for some configurations.
Comment #5
gregglesWhich version of drush are you using?
Comment #6
AohRveTPV CreditAttribution: AohRveTPV commentedGit master, just pulled. Maybe this is a bug that does not exist in other, release branches?
Non-working patch attached. I could drop the curly braces, but then it wouldn't work for table prefixes, presumably.
Note that this patch is for 7.x-2.x. The code you gave is for 7.x-1.x (different tables). We can add this to 7.x-1.x too.
Comment #7
AohRveTPV CreditAttribution: AohRveTPV commentedFWIW, I dropped the text "(depending on the site config, may contain sensitive data)" because I think the
password_policy_history
table almost always has sensitive data (hashes of users' previous passwords). They are stored by the module even if the history constraint is not used.Comment #8
AohRveTPV CreditAttribution: AohRveTPV commentedReported Drush issue:
https://github.com/drush-ops/drush/issues/1582
Comment #9
NancyDruWhat about people that don't Drush?