# Thunder Backend

The backend of Thunder is a monolithic Nodejs application implemented with the [Koajs 1.x](https://github.com/koajs/koa/blob/v1.x/docs/api/index.md) framework. It has the following features:

- Receives HTTP requests with JSON
- Authenticates with [JWT](https://jwt.io/)
- Broadcasts updates with socket.io
- MongoDB database

## Overview

`app.js` is the starting point of the server, and serves as a directory for the HTTP endpoints.

Most functionality is split into task specific modules. Generally this is a 1 to 1 relationship with collections in the database. These module files exist in the root directory of the repo (little messy). The modules contain the REST endpoints and most of the business logic / database interactions.

Any outgoing information besides HTTP responses goes through the ``Broadcast`` module which sends messages through socket.io to all logged in users.

## Installation

After cloning:

npm i

Create a ``serverConfig.js`` in the root folder with the contents:

module.exports = {
	facilities: ['CPS'],
	database: "mongodb://thunderdbcps:bluedogredclown5@104.131.96.255:27111/thunder",
	port: 80
}

Then run.

node app

You can update the frontend with gulp:

npx gulp

## Module endpoints

Typically,
- incoming data exists in the ``this.data`` object (for ``PUT`` & ``POST``), and/or in the ``this.params`` object (for ``GET`` & ``DELETE``).
- ``this.decodedToken`` also may have relevant data. Some user specific parameters - ``username``, ``facility``, ``role``, ``flags``, etc. are inside the JWT and are passed with each authenticated request.
- Outgoing data for the response is placed in the ``this.body`` with the HTTP status in ``this.status``

## Auth

Auth typically follows this flow:

- User logs in via a JSON HTTP request, the password is checked with their ``hash`` and ``salt`` and if successful, they are issued a [JWT](https://jwt.io/)
- The JWT carries their username, permission flags (``flags`` in the JWT and database) and an expiration date.
- The client is in charge of making sure they refresh their JWT before expiration occurs
- The client sends the JWT with every request (while logged in) in the ``Authorization`` header (**without** the ``Bearer `` syntax)
- Permission is checked as Koa middleware before reaching the endpoint. For example:

app.get('/user/:username', authed, User.getUser);

The ``authed`` here will make sure that the JWT with the request is both valid (issued by the server) and not expired. So any logged in user will be able to access a user via a username.

app.post('/user/resetPassword', has('managePasswords'), User.resetPassword);

Here, the ``has`` middleware will check that the JWT both is valid, *and* contains the ``managePasswords`` flag. So only users with the ``managePasswords`` permision can reset a password.

The authentication code exists mostly in ``auth.js`` and ``user.js``.

## Broadcasting

The idea behind broadcasting would that only certain people would want to listen to certain messages. To this end, messages sent from the server would have a structure like:

var Broadcast = require('./broadcast');

Broadcast.send({
    for: {admins: true},
    type: 'adminalert'
    data: {...}
});

but generally in practice the ``for`` field was ignored and was often just ``{}``.

On the client side, a module would listen for broadcasts with:

var Message = require('message');

Message.listen({for: {admins: true}, type: 'adminalert'}, function(data){

});