Alter database fields to accommodate encrypted content about field_encrypt HOT 6 CLOSED

What are the risks of altering a site's database schema?

• When migrating or deploying content from, say, development to production, if the schemas aren't identical, there will be problems.
• When a field is selected to be encrypted and there is existing data, that data would need to be copied to a temporary field, the database altered, then the data copied back to the new column, with encryption happening along the way.

To me, this method of storage is just fraught with too many potential problems. It would be better to copy a field's table and modify that—so, for instance, the structure for "node__body" would be copied to "node__body__encrypted" and then altered to accommodate encrypted data. Within Drupal, the Body field would then need to retrieve its data from the new db table.

from field_encrypt.

If we end up using a new table to store encrypted data, we will of course need to do the same for the field's revision table. So the structure for "node_revision__body" would be copied to "node_revision__body__encrypted" and altered.

from field_encrypt.

Talked on IRC with @nerdstein about this.
He mentioned a consideration made by him and @rlhawk is to use a content entity for storing the encrypted values.
It would be a content entity with reference fields to property, field, entity, entity id - and an encrypted value of type text.

I'm investigating this option. This is what I found so far:

• If we'd be able to set the "custom_storage" flag on the FieldStorageConfig to TRUE, no database tables will be created for this field.
• Through hook_entity_storage_load() we could find out which fields have the field_encrypt third_party_settings, and thus are encrypted fields. At this point we could load the encrypted value for this field (stored in the separate content entity or wherever would be appropriate), and set the field properties to their unencrypted values.

However, this will probably cause problems when some field properties should be encrypted (e.g. "value") and others shouldn't (e.g. "format"). In that case the custom_storage flag won't store the unencrypted values, from what I can tell...
Also, this approach currently makes Views throw SqlContentEntityStorageException's all over the place on my test install.

I'm not confident this is a solid approach, so other ideas or brainstorming are certainly welcome.

from field_encrypt.

Extra clarification on the desired approach of @nerdstein:

The idea would be to leave the entity as intact as possible.
Upon saving the entity, field properties to be encrypted should then be stored with a NULL / empty value - or maybe not stored at all (via setCustomStorage(TRUE)).
Upon loading the entity, field properties would be populated with the unencrypted values, loaded and unencrypted from a ContentEntity (e.g. EncryptedFieldValue) that had the encrypted value stored.
Upon deleting the entity, cleanup actions should be performed.

To check what (unwanted) consequences this approach might have (e.g. regarding Views, render caching, ...)

from field_encrypt.

TODO:

• add hook to change "[ENCRYPTED]" value to something else, based on the field type.

from field_encrypt.

The requested functionality from this issue has been implemented.
There are some follow-up issues still open, but we can discuss things over there.
Closing this one.

from field_encrypt.