Small microservice built with Go to enable users of Sirius to download multiple files from S3.

• Go 1.14.2
• Docker with docker-compose

• GoTestSum - go test runner with optimized output

Use docker-compose commands to build/start/stop the service locally e.g. docker-compose up --build will rebuild and start the service.

By default the local URL is http://localhost:8000/services/file-service, where /services/file-service is configured by the PATH_PREFIX ENV variable.

Run make test to execute the test suites and output code coverage for each package.

End-to-end tests are executed as part of the make test command.

Generally they sit in main_test.go. The test suite will start up the file service in a go-routine to run tests against it, and therefore all ENV variables required for configuring the service have to be set prior to running the test suite. This is all automated with the make test command.

Run make docs or make swagger-up to view swagger docs at http://localhost:8383/

Run make swagger-generate to update the swagger.yml file

The file service uses Go Swagger to generate the ./swagger.yml file from annotations in the code itself. See ./main.go for examples. Go Swagger is based on Swagger 2.0. Be careful not to confuse it with OpenAPI v3.

Another gotcha... Make sure annotations are written with 2 space tabs in order for the parser to work correctly!

• GET /health-check - returns a 200 status code if the file service is running
• POST /zip - TODO - Creates a new Zip request and stores it in the database. On success it returns a Reference token that can be used in the GET /zip/{reference} endpoint to download the zip.
• GET /zip/{reference} - Finds a Zip request by Reference and streams a zip of all files associated with the Zip request.

All requests (except for health-check endpoint) are passed through a JWT authentication middleware that performs the following checks:

• JWT token is present in the Authorization header in the format: Authorization: Bearer JWT_GOES_HERE
• JWT token is valid
• JWT token is not expired
• JWT token is signed with the correct key (JWT_SECRET ENV var) using the correct signature method (HMAC-SHA by default)

The middleware will also create a SHA-256 hash of the session-data value from the JWT payload, which usually contains an email address. This hash is stored with all Zip requests and is subsequently used for verifying that the user downloading a zip is the same user that created the Zip request in the first place. The salt for this hash is defined in USER_HASH_SALT ENV var.