GSoC Week 9: encrypt_content_client - update data-keys

Feature complete

I have completed all of the features described in the design document which means that my module is feature complete! There is some work left to do: bug fixes, functional tests, documentation, user scenarios, making the module robust, security audit and few small things on the backlog that have came up during development from either me or my mentors.

As instructed by Colan I have created an official module on I will submit this link to my final code submission.

Module’s documentation

As the final deadline is approaching I am starting to work on the documentation for the module. This file will include basic instructions on how to get required libraries and do the initial configuration. I have also thought about a few user cases and scenarios, and made sure the features that I had implemented support those.

Extending the content list view

Implementing these features includes adding a new column to the content list. I used the Views module’s hook to extend the content view list. I used the hook_views_data_alter.

Extended list view


I have included following scenarios for encryption status:

  • Content is not encrypted. (module may have been after the node has been created)

  • Content is encrypted for every user. (no action needed)

  • Content is inaccessible. (current user is not included in the encryption container - he or she cannot trigger date-key update process)

  • Data-keys needs to be updated. (content is not encrypted for every user)

Following article was very useful when editing an existing view:

Data-keys update process

This process has few user cases for being triggered:

  • An user has been added or deleted

  • An user has her or her client encryptions permission granted or revoked.


I came up with a neat solution to re-encryption process as my previous design provided a really nice base. Here is a breakdown of re-encrypting single node:

  1. Call the reEncryptNode function with arguments received from the backend function or front-end button - node’s type and ID.

  2. Get the encrypted container for the given node.

  3. From received container, get encrypted data key for currently logged in user.

  4. Generate dataKey and update the encryption container.

  5. Retrieve encrypted fields through REST.

  6. Decrypt fields using previously retrieved dataKey.

  7. Encrypt fields with new dataKey and then push them to the database.

More robust encryption containers and fields REST

Now that I am working on the re-encryption process I have added more robustness to the REST resources I had created earlier.

For example: updating encrypted fields instead of adding more entries when you edit a node, encryption container also gets updated when it exists in the database. I am also using GET/POST requests for inserting new entries and updating existing ones. This design also takes some work off the JavaScript functions as checks are made on the back-end.

Following Talha's comment I also added DELETE calls to module’s REST resources.

Plans for week 10

  • Functional tests for PHP and JavaScript features.

  • Think of a more robust way of creating nodes through REST.

  • Work on the module’s documentation.

  • Create a few user cases and include them in the architecture document.