GSoC ’17 : Client Side File Crypto : Week 1

Note: This is a repost of the original Blog post during GSoC ’17. As my AWS instance went down, I’ve been migrating my old blog posts here.
Originally posted on: 7th June 2017

This blog post summarises the one week that has elapsed writing code for Drupal as a part of my Google Summer of Code Project, client side file cryptography.

Of the several things I’ve learnt this week, one was realising how huge of an organisation Drupal is, it is probably one of the largest open-source communities! For anything that you are stuck with while developing for Drupal, just searching for that issue on the internet would give you a plethora of pages with discussions, documentation and answers related to that issue, which is probably not the case with most open source organisations. For most things there is ample documentation (both official and unofficial) on the internet. There is a dedicated StackExchange forum for Drupal named “Drupal Answers”.

The week began with building the bare minimum basic framework of files that is required for all Drupal 8 modules to function, i.e. most of the yaml files: .info.yml that lets Drupal know about the existence of the module, .routing.yml that defines all the routes to the controllers used in the module. I decided to go with “Client Side File Crypto” as the module name and “client_side_file_crypto” as the machine name for the module.

Later, I added necessary hooks in the .module file like the hook_user_login hook that will be triggered every time a user logs in. More such hooks would be appended to the .module file later with the development of the module. Another hook included there is the _help hook that would provide a help page for the module that can be accessed from the “extend” section by the administrator.

All the storage systems required on the backend were completed. For storing the public keys on the server, as Colan recommended, I registered a new user field in the user entity. This took a while to figure out as I had some confusion between “custom content types” and “custom field types” as the official Drupal documentation instructed to add custom fields under custom content types and the tutorial instructed to make a new custom entity. It was finally accomplished by adding two yaml files in the config/install/ directory, namely field.field.user.user.pub_key.yml and

For storing the access keys of the user, a database table was registered named “client_side_file_crypto_Keys”. The following image shows the structure of the table.

I also made two controllers and their corresponding routes that will be redirected to on a condition of if the user is logging in for the first time when they log in using hook_user_login().

Later, I added all the JS libraries and defined the several JS libraries in the .libraries.yml file. I’ve defined three libraries for the module:

[libraries img]

These libraries can be included in the render arrays and it will load all the mentioned JS files and the jQuery dependency as mentioned in each of the libraries.

I made a few more iterations over the Architecture document after reviews from Colan and Talha and here’s a link to the final Architecture document.

As most of the work being performed by the module would be on the browser and the only major function on the server of storing and retrieving the keys, I’m currently working on exposing the API for use by the JavaScript using the REST module. This will be used for fetching and storing the keys and files to and from the server.

For the upcoming week, I’ll be completing the key manager for the backend, setup the REST Resources for fetching the keys and the asymmetric key generator for generating and storing the asymmetric keys on the server and client.
Thanks for reading! :)

Like what you read? Give Tameesh Biswas a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.