GSoC 17 Client Side File Crypto : Week 3

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: 21st June 2017

This post summarises my third week of coding with Drupal for Google Summer of Code 2017.

Reshaping the REST API

In last week’s meeting with my mentor, Colan recommended that I should make my REST Resource more RESTful and Resource oriented. So I did a bit more research into “Ideal RESTful Resources” and found out this article and made my REST API more RESTful and Resource oriented. I also made the resource request paths as nouns unlike their verb forms as they were before. Now the REST resource is making proper use of both GET and POST requests to read and write the keys/resources.
There are some more changes that are to be made to the REST resources’ HTTP response codes and some other changes after the code review.
Following is a model of the new REST resource, as also outlined in the architecture document.

RESTful resources:

• publicKey/
• GET: Gets the public key for current user.
  Headers: Basic Authorization
  No parameters
  Example Request URL: http://localhost:8000/publicKey/?_format=json
  Example response:
  {
  publicKey”: “aRandomPublicKeyHere”,
  “uid”: 1,
  “message”: “Success!”,
  status”: 1
  }
• POST: Registers new public key to the current user’s pub_key user entity field.
  Headers: Basic Authorization
  X-CSRF-Token
  Content-Type:application/json
  Example Request URL: http://localhost:8000/publicKey/?_format=json
  Request Body:
  {
  “publicKey” : “aRandomPublicKeyHere”
  }
  Example response:
  {
  status”: 1,
  “ message”: “Successfully added.
  }
• publicKey/{uid}
• GET:get specific user’s public key
  Headers: Basic Authorization
  Parameter : $uid : userID of the user
  Example Request URL: http://localhost:8000/publicKey/1?_format=json
  Example response:
  $uid=1 :http response code 200
  {
  “publicKey”: “aRandomPublicKeyHere”,
  “uid”: “root”,
  “message”: “Success!”,
  “status”: 1
  }
  $uid=2(does not exist):http response code 400
  {
  “message”: “Error loading User!”,
  “status”: -1
  }
• accessKey
• GET: get’s the logged-in user’s access key.
  Headers: Basic Authorization
  No parameters
  Example Request URL: http://localhost:8000/accessKey/?_format=json
  Example response:

• POST: register a new access key.
  Headers: Basic Authorization
  X-CSRF-Token
  Content-Type:application/json
  Example Request URL: http://localhost:8000/accessKey/?_format=json
  Request body:
  {
  “accessKey”:”someRandomAccessKey1",
  “roleName”:”administrator”,
  “userID”:”1"
  }
  Example response:
• accessKey/pending
• GET : Returns the pending access key requests.
  Headers: Basic Authorization
  No parameters
  Example Request URL: http://localhost:8000/accessKey/pending?_format=json

Custom JS Hooks

I had set up the JavaScript placeholders for post login JS hooks in the last week. Until last week there was only a scaffolding .libraries.yml for the JS. This week I implemented the intended JS hooks including both post-login landing pages. Although, in the last meeting with Colan, we discussed alternate ways to implement these hooks as redirecting the user to a different page post every login might be a bit irritating to the user. Also, there’s this case where a user doesn’t ever logout and pending keys are never checked for from his account.

Register New Asymmetric Key Pair

This is one of the custom JS hooks that was implemented. The user is redirected to this page after the first time they login post module installation.

This is handled by the client_side_file_crypto.newKeys route on the /user/newKey path. The browser generates an RSA key pair using the jsencrypt library. The publickey is sent to the server utilising the REST Resource /publicKey, sending a POST request to it with a JSON object in the body of the request and the X-CSRF-Token and content-type headers.

AccessKey Provider

The second login onwards the user lands on a different page, handled by the client_side_file_crypto.postLogin route on the /user/postLogin path. This was the first page involving any encryption/decryption and houses multiple nested AJAX methods. What this script does is that it sends a GET request to the /accessKey/pending to receive a JSON object response and later parses it to run a forEach loop sending a newly generated access key for each of the access key requests to /accessKey via the POST method.

First code review

Later this week I also had the first code review on the code that I had pushed so far. There are several things that I learnt from it, one of them being the fact that third-party javascript libraries shouldn’t be committed with the code and the reasons behind it. I will be fixing and making the recommended changes from the review toward the beginning of the upcoming week.

Challenges and and some interesting things I learnt

Every week of coding with Google Summer of Code, I get to learn interesting new things, where some weeks with more challenging parts teach a quite a lot new things. This week, initially was a bit challenging as I was getting various HTTP error codes as the response from my REST resource, while trying to overcome this issue I learnt quite a bit about the csrf attack and the X-CSRF-Tokens.

The upcoming week involves more interesting, yet challenging work as that would be the major part what is left of the module, the encryption of files. I consider it challenging as I’ve never handled binary files and BLOB objects in JavaScript and it would surely bring a lot of new things to learn about like web workers, FileReader & Blob objects. I will be starting the week with resolving issues from the code review and then heading on to researching prerequisites for file encryption on the client side.
Looking forward to an exciting week! :D Thanks for reading!