How to migrate from Strongbox about lockbox HOT 6 CLOSED

Yeah, that's correct (email_migrating is migrated_email). The extra attribute is an implementation detail that users shouldn't need to worry about, so I don't think it makes sense in the readme.

from lockbox.

For who is interested, in the Migrator class I changed record.send("#{v[:attribute]}=", record.send(k)) unless record.send(v[:encrypted_attribute]) to decrypted_value = record.send(k).decrypt Rails.application.secrets.token_encryption_password record.send("#{v[:attribute]}=", decrypted_value) unless record.send(v[:encrypted_attribute]).

In the Model class, I changed the code:

define_method "#{original_name}=" do |value|
  result = super(value)
  send("#{name}=", send(original_name))
  result
end

to

define_method "#{original_name}=" do |value|
  result = super(value)
  send("#{name}=", value)
  lock_for(original_name).content value
  result
end

This will allow to migrate existing data and keep the attribute and migrated_attribute in sync, allowing to run Strongbox and Lockbox side by side. The change is not totally complete though because strongbox has a different syntax for setting an attribute to a nil value. Therefore for a successful migration we have to be careful in setting migrated_attribute to nil whenever a one of the original attributes is nullified.

from lockbox.

Hey @mzanini, it's probably easiest to fork the gem, replace the send calls, and then switch back after migrating. The two places you'll want to change off the top of my head are the migrator class you mentioned and the model module (may be able to replace send(original_name) with value).

I haven't tried strongbox, so there may be more work involved.

Edit: Basically, migrating consists of two parts: keeping the column in sync with new updates (the model module, which allows for zero downtime) and backfilling existing data (the migrator class)

from lockbox.

Thank you for your answer! To clarify how the migration process works right now (I think this could be added to the readme): let's say I want to migrate the email attribute on the User model.

1. Adding encrypts :email, migrating: true will add an attribute email_migrating to the model.
2. Assigning a value to email will cause email_migrating to be assigned that value too.
3. Whenever the value of the email_migrating attribute is set, lockbox will encrypt the value and save it to the DB column email_ciphertext.
4. Running Lockbox.migrate(User) will set email_migrating = email for every record
5. Removing the migrating: true option will map the email attribute to the email_ciphertext column

Is that right or are thing working in a different way?

from lockbox.

Perfect, thanks for clarifying!

from lockbox.

Awesome, thanks for sharing @mzanini! This should be really helpful for others in the same situation.

from lockbox.