search

d8-contrib-modules / field_encrypt

CODE HAS BEEN MOVED TO https://www.drupal.org/project/field_encrypt
0 stars 5 forks source link

Provide alternatives to "[ENCRYPTED]" storage values for other field types. #40

Closed svendecabooter closed 8 years ago

svendecabooter commented 8 years ago

This is a follow-up to https://github.com/d8-contrib-modules/field_encrypt/pull/38

TravisCarden commented 8 years ago

This issue will be a critical blocker for sites that need to encrypt financial data, for example. It already is for me.

Drupal\Core\Entity\EntityStorageException: SQLSTATE[HY000]: General error: 1366 Incorrect decimal value: '[ENCRYPTED]' for column 'field_price_value' at row 1: INSERT INTO {node__field_price} (entity_id, revision_id, bundle, delta, langcode, field_price_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 1165 [:db_insert_placeholder_1] => 1165 [:db_insert_placeholder_2] => example [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => en [:db_insert_placeholder_5] => [ENCRYPTED] ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 757 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

nerdstein commented 8 years ago

If I recall, we had to set values because the solution did not work without it. (e.g. something in core was expecting some value).

Theres two avenues here...

  1. We keep this for strings and try just removing any value for numeric / date / or other core provided data types. We would need a hook for other custom field values to set their own value (or lack thereof)
  2. We explore why we couldn't save nothing and try to submit a core patch or revisit alternatives so we have no default values - which is both confusing and clunky (misrepresenting the fact that the data value is stored altogether elsewhere)
svendecabooter commented 8 years ago

I have created a new PR that sets some sensible placeholder values, based on the property data type.

We should indeed probably explore how we can let Drupal core know that there is a particular value for the field (stored encrypted elsewhere), without having to provide a placeholder.

But until we've found a way to handle that (if possible at all), the PR at least makes sure that current core field types don't result in errors when trying to encrypt them.