GSoC Week 8: encrypt_content_client - table for encrypted fields

Configuration page for my module

Before I did any additional work on the encryption/decryption processes I had to implement a more robust way of declaring which entities and fields to encrypt. After talking to Colan and Talha I decided to go with following approach, first step was to create a configuration page:

Configuration page

Administrators will be able to choose which entities to encrypt and then have a set of checkboxes with field names to select from. After selecting which fields to encrypt, this information will be saved to Drupal’s default config storage option.


In order to create above page I had to get a list of all content entities, then create a route with {entity} parameter, then I retrieved all fields for given entity. The next step was to filter out all read-only ones. I used checkboxes with field names loaded from config storage.

Fields list

After doing this I was able to retrieve an array of fields that site’s admin wants to encrypt on the JavaScript side. I have also added few lines to the .install file so it now adds fields title and body to the article node type by default to improve testing and user experience in the future.

Table for storing encrypted fields

As mentioned in the previous week I was changing the design a bit as I reached some limitations. Now that I have a list of what fields need to be encrypted, I can make my encryption function more robust, instead of using hard coded list of fields’ IDs.

Ecrypted fields list


Now that I have reworked the encryption system to include an array of field names - with the entity type as the key. The next step was to use similar approach for decrypting fields. Now I have a robust way of determining which fields to encrypt, it works great for basic title and body fields but other fields may need some more tweaking.

Removing the initial development scaffolding

As my module is more stable now, I went through my code and removed sandbox and  scaffolding functions which I used to support the initial development phase.

Few examples are removing the private key field and REST resource method for retrieving it, removing the sandbox page, and I went through my JavaScript code and removed debugging options etc.

Start designing test cases

Now that my module has the main functionality done and it’s fairly stable I can think of writing initial tests. If I change any of the core features I can always go back a step and change already existing tests. I have been trying to write tests as I coded, but did not get satisfactory results.

Another interesting thing to look into is testing the creation of encrypted nodes, as my module is mostly based on JavaScript features. Starting the following week I will include JavaScript tests for encryption and decryption on the front-end using BrowserTests.

Here is some good resources on writing tests in Drupal 8:

Interesting issues

  • /entity/node?_format=json 406 (Not Acceptable)

Suddenly the method for creating new nodes through REST that used to work - now started to give above error. I realized that I switched to a different Drupal instance and that in the previous one I manually enabled this REST call along with JSON format.

That reminded me that I have to gather such issues in a document I can then use to create a first time user guide, a set of instructions for the installation of my module.

Plans for week 9

  • Start writing tests for PHPUnit and JavaScript features using BrowserTests.

  • Decrypting ciphertext when viewing nodes.

  • Start implementing re-encryption process for given node outside of an edit/create forms.

  • Write few PHP functions which are safe to be handled on the server side:

    • Check if entity is encrypted for every user in the system