-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🔐 Marketplace
: Encrypt Order#delivery_address
!
#1169
Conversation
267d6f8
to
4ef019d
Compare
Marketplace
: Encrypt delivery addresses!Marketplace
: Encrypt Order#delivery_address
!
why? because that rake task is only temporarily needed to migrate the old prod data? And we don't need to keep it around because it won't ever be reused... right? |
Aren't we also storing the contact person's email address too after every stripe order... is that PII (personal identifiable information) too that needs to be encrypted? |
class MarketplaceEncryptOrderDeliveryAddress < ActiveRecord::Migration[7.0] | ||
def change | ||
rename_column :marketplace_orders, :delivery_address, :deprecated_delivery_address | ||
add_column :marketplace_orders, :delivery_address_ciphertext, :text |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lockbox gem says it's possible to encrypt the existing column here.... but maybe it's statement is deceptive. It's steps looks like you'd still need to create a new column for encrypted data. migrate the data, and drop the column of unencrypted data. 🙄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, the migrating syntax is neat! I didn't realize it existed; but yea, that would save us the rename_column
step and having to write the find_each
!
It's also likely far safer in high-throughput cases; because you would still be able to access the delivery_address
while it's being migrated; where as with this there is a moment in time where delivery_address
is nil until the data migration completes.
I'll definitely do it next time!
lib/tasks/release.rake
Outdated
next unless order.deprecated_delivery_address.present? | ||
|
||
order.update(delivery_address: order.deprecated_delivery_address, deprecated_delivery_address: nil) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see.. this is the prod data migration.....
So.. I assume this rake task runs BEFORE the delivery_address
column is renamed in 20230302202459_marketplace_encrypt_order_delivery_address.rb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, let me step ya through the Heroku deploy process:
- Heroku checks out the git repository, and starts a build which creates a new
image
and installs gems, node packages, etc. - Heroku launches a
release
container using the newimage
, and runs therelease
command defined in theProcfile
, which runs therails db:migrate
and release:after_build` tasks in sequence - Launches new
web
andworker
containers using the newimage
. - Begins routing traffic to the new
web
containers - Stops routing traffic to the old
web
containers - Shuts down the old
web
andworker
containers.
So the database has the new columns prior to running the rake task, and before deploying new web
and worker
containers. this means that the existing web
and worker
containers will still be running the code which references delivery_address
, which could result in sql query errors. We could install strong_migrations
to catch risky operations (like rename
s); but in this particular case I felt like it was safe enough given our traffic.
That said, there's no reason not to use the Lockbox.migrate
strategy; which eliminates the risk and seems pretty dang cool!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created issue #1177 to install strong_migrations.
My work team uses it and it is really handy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yah!!!!
app/furniture/marketplace/order.rb
Outdated
@@ -11,7 +11,7 @@ class Order < Record | |||
has_many :ordered_products, inverse_of: :order, foreign_key: :cart_id | |||
has_many :products, through: :ordered_products, inverse_of: :orders | |||
|
|||
attribute :delivery_address, :string | |||
has_encrypted :delivery_address |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the order of operations for everything this code change does?
Seems like in this change...
:delivery_address
is being renamed todeprecated_delivery_address
- data in
deprecated_delivery_address
is migrated todelivery_address_ciphertext
- data in
deprecated_delivery_address
is replaced withnil
And in later PR... I assume this happens?:
4. deprecated_delivery_address
is dropped.
5. delivery_address_ciphertext
is renamed delivery_address
so has_encrypted :delivery_address
in Order
model still works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes except step 5 never happens; because the Lockbox
infers that delivery_address_ciphertext
is the database name for the encrypted delivery_address
attribute.
Yep!
Good catch. This is part of why we have the |
@KellyAH found Lockbox's guide to migrating data: https://github.com/zinc-collective/convene/pull/1169/files#r1124067175 And it's way better!
4ef019d
to
2fdd8a3
Compare
@KellyAH - I swapped to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢
Marketplace
:DeliveryArea
#1136Gizmo
:Marketplace
#831So, I totally didn't think about how delivery addresses are PII and probably should not be stored in plaintext! Womp. Womp. Womp.
Now they ain't!
We'll want to delete the
release:after_build
bits after a prod deploy.