Skip to content

jpburbank/hmac_token

Repository files navigation

Uplight Technical Assessment

Author

Johnpaul Burbank

jpburbank@gmail.com

Summary

The following is my submission for the assigned problem of creating an endpoint to append a HMAC token to a request body. The specifics of the assigment can be found in the file that was given to me

Uplight Technical Assessment - June 2021.pdf

Assumptions

I have made the assumptions that all keys and values found in the user supplied JSON will be UTF-8.

Dependencies, Installation & Running

Python 3.9.4 was used to create this. Dependency management was done with Poetry and that will be required to build this. Installation steps for Poetry can be found at https://python-poetry.org/docs/#installation. It will be different for Windows VS Linux, OS/X, but both are simple and quick.

Once Poetry is installed, the dependencies will be resolved by issuing the following command at the root of app, on the command line

poetry install

If you are not familiar with Poetry and are curious about where the dependencies are defind, you will find them in

pyproject.toml

To make sure you are running with the correct Python and dependencies, issue the following command

poetry shell

To run the server, issue the following command

uvicorn main:app

The ASGI server, uvicorn should be installed by the prior command to load dependencies. If this is successful, a server will be running on http://127.0.0.1:8000

Hitting the API

The API will only respond to a POST request, as listed in requirements. It will require a JSON body, and it technically does not need to have anything in the JSON. An open and close curly brackets would be sufficient. If using CURL on the command line, the following would is an exmaple of a working request.

curl --request POST --url 'http://127.0.0.1:8000/' --header 'Content-Type: application/json' --data '{"id": "MDAwMDAwMDAtMDAwMC0wMDBiLTAxMmMtMDllZGU5NDE2MDAz"}'

Notes

The assigment description given to me contained examples with simple JSON POST bodies. Both with single values each. The solution I've provided will allow for multiple values in the JSON. This includes nested JSON objects and arrays. The ordering of collection values is also pertinent to the signature generated. As the keys and not just the values are used to update the digest, a JSON object with the same keys, but defined in a different order will generate a different signature. This is the same for values in JSON arrays. I'm sure given the time spent and the lack of code review there are likely edge cases missed. A JSON body like the following will work.

{
"id": "MDAwMDAwMDAtMDAwMC0wMDBiLTAxMmMtMDllZGU5NDE2MDAz",
"zev": 123445,
"name": "bob",
"ls": ["asd", "ert", "dfgs"],
"aaa": 12.45,
"next": {
	"id": "LTAxMmMtMDllZGU5NDE2MDAzMDAwMDAwMDAtMDAwMC0wMDBi",
	"name": "luke",
	"zev": 5551,
	"aaa": 54.2,
	"new": false
  }
}

As required by HMAC, there is a secret key. For lack of a better place, I have put this in .env to keep it out of source code. With this approach the .env file would not be added to git. A more sensible place would be a key value pair store provided by a cloud service and protected by an elevated role.

Source Control & Files

Git has been used for soure control for this application. If you wish to see its progressions, you will find it at, https://github.com/jpburbank/hmac_token. It is currently a public branch, as I don't know who will be looking at it. I'm sure you do not want an Uplight interview assignment up for people to see, and so I will be setting it to a private repo after tomorrow's (June 10) interviews. Of course, If anyone wishes for it to be private immediately, please send me an email at jpburbank@gmail.com

The Git meta files will be stripped from tarred and gzipped submission.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published