d8-contrib-modules / field_encrypt Goto Github PK

If I encrypt the node.panelizer field panels_display property, Panelizer changes cease to save. They seem to, and no errors are shown or logged, but if I refresh the page after the UI indicates it has finished saving, the change I just made will be absent. If I turn off encryption for the property and follow the same steps, it saves and persists just fine.

Currently when the field storage settings get changed, a Batch API process updates the existing field values accordingly.

We'd also need to check how we can make this work if the settings change through a CMI update, i.e. settings get changed in dev and are then pushed to production.

Add an UninstallValidator service, that checks if field_encrypt still has fields encrypted, before being able to be uninstalled.

I received the following error on a fresh copy of Drupal 8.0.7 when installing the module and when attempting to visit the site in a browser or interact with it via Drush:

Fatal error: Cannot call abstract method Drupal\Core\Entity\FieldableEntityInterface::baseFieldDefinitions() in field_encrypt/src/Entity/EncryptedFieldValue.php

@damontgomery - I thought maybe we could do a full code review before socializing the progress. Thoughts?

Follow up to #36

When a field is encrypted, it will always be longer than the original unencrypted text, and it may be a different type. This means that the database field that will store the encrypted data might need to be altered in order to accommodate the new content.

It's a bit risky to try to make guesses about how large a field needs to be. For instance, a boolean value, when encrypted, is not likely to exceed 255 characters, but depending on the encryption method, it is quite conceivable that it could. The safest way to go would be to always change the field to "text big", but that's almost certainly overkill for the vast majority of use cases. Boolean fields, for example, could safely be stored in a "text" field, which translates to 65,535 characters in MySQL. Field Encrypt 7.x-1.x-dev handles this issue by changing any fields with encrypted data to "text medium," which undesirably reduces the size of Long Text fields, such as Body.

I assume that the database alteration would happen upon submission of the Field Settings form—either changing the db field to allow for encrypted data or changing it back to the original type and size.

The architectural documentation should be updated with the latest changes.

We would like to be able to have the default for an entity type's fields to be encrypted. But, we would also like to have a hook in place where you can selectively say you would not like any of the fields on the entity to be encrypted.

The use case is this:

1. We are going to be encrypting every field on every content type.
2. We only need the content to be encrypted when a piece of content is unpublished.
3. When a piece of content is published, we would want that revision to be stored unencrypted.

Motivation: For published content, we want to be able to use render cache and not to have the overhead of decrypting content for every field on every piece of content.

1. How do we extend the field creation process to create a new field for encrypt option?
2. Should we separate this by field type? (e.g. different classes for types of fields, turn different field types on and off based on settings?)

Right now the encrypt_stored_field() and decrypt_stored_field() methods do not use a batch process.

This may become an issue if there is a large number of entities on a site and it may be worth adding a batch process to the module.

This is a follow-up to #38

Use Drupal console for the following:

1. info file, dependency to encrypt
2. module file stubbing out entity presave and load hooks
3. src/Tests and a placeholder simpletest
4. .travis.yml (can copy basics from another module)
5. readme.md with basics stubbed out

See #28

I'm trying to implement this module on my project. I've succeeded in getting selected fields on a given content type encrypted, but I haven't found any scenario in which they ever get decrypted again--neither on node display nor on node edit accessed as user 1, whom I created my test nodes with. I can see the rows in encrypted_field_data, and I see field_encrypt_entity_storage_load(), which purports to do the decryption. What am I missing? Is there some kind of code or configuration needed to define the business rules for when decryption actually takes place?

\Drupal\field_encrypt\FieldEncryptProcessEntities::checkField() tries to call two non-existent methods, \Drupal\Core\Field\BaseFieldDefinition::get() and Drupal\Core\Field\BaseFieldDefinition::getThirdPartySetting(), resulting in fatal errors. I experience them when attempting to log into my site after having just installed the module.

I just installed these three sets of dependencies and translations aren't being displayed appropriately. Here is what I did.

1. Enabled all modules (workbench moderation, key, encrypt, field encrypt, real_aes, content translations, translate)
2. Set up workflow states (draft, review, publish, archive) and transitions between each state
3. Added workflow to basic page content type
4. Added a test key and encryption profile.
5. Enabled French translation on the site
6. Encrypted the body field on the basic page
7. Created a basic page node and transitioned to review
8. Created a french translation of the node and saved as draft

Expected result, viewing the french draft would display the french content

Actual result, viewing the french draft shows the english content.

This works as expected when workbench moderation is not being used.

The whole point of encryption would be flawed if the caching system stored a decrypted field value (e.g. rendering/render array).

How do we solve this problem?