d8-contrib-modules / field_encrypt Goto Github PK
View Code? Open in Web Editor NEWCODE HAS BEEN MOVED TO https://www.drupal.org/project/field_encrypt
CODE HAS BEEN MOVED TO https://www.drupal.org/project/field_encrypt
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.
\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.
This is a follow-up to #38
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?
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
Add an UninstallValidator service, that checks if field_encrypt still has fields encrypted, before being able to be uninstalled.
Use Drupal console for the following:
Follow up to #36
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?
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:
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.
@damontgomery - I thought maybe we could do a full code review before socializing the progress. Thoughts?
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.
See #28
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.
The architectural documentation should be updated with the latest changes.
I just installed these three sets of dependencies and translations aren't being displayed appropriately. Here is what I did.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.