Migrate to Auth0 as Identity Provider

This pull request removes the hard dependency on Google for 
authenticating users and migrates to Auth0 as Identity Provider for OpenDC. 
This has as benefit that we can authenticate users without having to manage 
user data ourselves and do not have a dependency on Google accounts anymore. 

- Frontend cleanup:
   - Use CSS modules everywhere to encapsulate the styling of React components.
   - Perform all communication in the frontend via the REST API (as opposed to WebSockets).
      The original approach was aimed at collaborative editing, but made normal operations 
      harder to implement and debug. If we want to implement collaborative editing in the 
      future, we can expose only a small WebSocket API specifically for collaborative editing.
   - Move to FontAwesome 5 (using the official React libraries)
   - Use Reactstrap where possible. Previously, we mixed raw Bootstrap classes with 
      Reactstrap, which is confusing.
   - Reduce the scope of the Redux state. Some state in the frontend application can be 
      kept locally and does not need to be managed by Redux.
   - Migrate from Create React App (CRA) to Next.js since it allows us to pre-render
      multiple pages as well as opt-in to Server Side Rendering.
   - Remove the Google login and use Auth0 for authentication now.
   - Use Node 16
- Backend cleanup:
   - Remove Socket.IO endpoint from backend, since it is not needed by the frontend 
      anymore. Removing it reduces the attack surface of OpenDC as well as the maintenance efforts.
   - Use Auth0 JWT token for authorizing API accesses
   - Refactor API endpoints to use Flask Restful as opposed to our custom in-house 
      routing logic. Previously, this was needed to support the Socket.IO endpoint, 
      but increases maintenance effort.
   - Expose Swagger UI from API
   - Use Python 3.9 and uwsgi to host Flask application
- Actualize OpenAPI schema and update to version 3.0.

**Breaking API Changes**

* This pull request removes the users collection from the database table. Instead, we now use the user identifier passed by Auth0 to identify the data that belongs to a user.

1 files changed, 43 insertions, 22 deletions

diff --git a/opendc-web/opendc-web-api/README.md b/opendc-web/opendc-web-api/README.md
index 4932f823..d1c469c1 100644
--- a/opendc-web/opendc-web-api/README.md
+++ b/opendc-web/opendc-web-api/README.md
@@ -9,15 +9,19 @@
 
 <br>
 
-The OpenDC web server is the bridge between OpenDC's frontend and database. It is built with Flask/SocketIO in Python and implements the OpenAPI-compliant [OpenDC API specification](../../opendc-api-spec.yml).
+The OpenDC web server is the bridge between OpenDC's frontend and database. It is built with Flask/SocketIO in Python
+and implements the OpenAPI-compliant [OpenDC API specification](../../opendc-api-spec.yml).
 
-This document explains a high-level view of the web server architecture ([jump](#architecture)), and describes how to set up the web server for local development ([jump](#setup-for-local-development)).
+This document explains a high-level view of the web server architecture ([jump](#architecture)), and describes how to
+set up the web server for local development ([jump](#setup-for-local-development)).
 
 ## Architecture
 
-The following diagram shows a high-level view of the architecture of the OpenDC web server. Squared-off colored boxes indicate packages (colors become more saturated as packages are nested); rounded-off boxes indicate individual components; dotted lines indicate control flow; and solid lines indicate data flow.
+The following diagram shows a high-level view of the architecture of the OpenDC web server. Squared-off colored boxes
+indicate packages (colors become more saturated as packages are nested); rounded-off boxes indicate individual
+components; dotted lines indicate control flow; and solid lines indicate data flow.
 
-![OpenDC Web Server Component Diagram](misc/artwork/opendc-web-server-component-diagram.png)
+![OpenDC Web Server Component Diagram](docs/component-diagram.png)
 
 The OpenDC API is implemented by the `Main Server Loop`, which is the only component in the base package.
 
@@ -25,74 +29,91 @@ The OpenDC API is implemented by the `Main Server Loop`, which is the only compo
 
 The `Util` package handles several miscellaneous tasks:
 
-* `Database API`: Wraps database access functionality used by `Models` to read themselves from/write themselves into the database.
+* `Database API`: Wraps database access functionality used by `Models` to read themselves from/write themselves into the
+  database.
 * `Exceptions`: Holds definitions for exceptions used throughout the web server.
 * `Parameter Checker`: Recursively checks whether required `Request` parameters are present and correctly typed.
-* `REST`: Parses SocketIO and HTTP messages into `Request` objects, and calls the appropriate `API` endpoint to get a `Response` object to return to the `Main Server Loop`.
+* `REST`: Parses HTTP messages into `Request` objects, and calls the appropriate `API` endpoint to get a `Response`
+  object to return to the `Main Server Loop`.
 
 ### API Package
 
-The `API` package contains the logic for the HTTP methods in each API endpoint. Packages are structured to mirror the API: the code for the endpoint `GET api/projects`, for example, would be located at the `endpoint.py` inside the `projects` package (so at `api/projects/endpoint.py`).
+The `API` package contains the logic for the HTTP methods in each API endpoint. Packages are structured to mirror the
+API: the code for the endpoint `GET api/projects`, for example, would be located at the `endpoint.py` inside
+the `projects` package (so at `api/projects/endpoint.py`).
 
-An `endpoint.py` file contains methods for each HTTP method it supports, which takes a request as input (such as `def GET(request):`). Typically, such a method checks whether the parameters were passed correctly (using the `Parameter Checker`); fetches some model from the database; checks whether the data exists and is accessible by the user who made the request; possibly modifies this data and writes it back to the database; and returns a JSON representation of the model.
+An `endpoint.py` file contains methods for each HTTP method it supports, which takes a request as input (such
+as `def GET(request):`). Typically, such a method checks whether the parameters were passed correctly (using
+the `Parameter Checker`); fetches some model from the database; checks whether the data exists and is accessible by the
+user who made the request; possibly modifies this data and writes it back to the database; and returns a JSON
+representation of the model.
 
-The `REST` component dynamically imports the appropriate method from the appropriate `endpoint`, according to request it receives, and executes it.
+The `REST` component dynamically imports the appropriate method from the appropriate `endpoint`, according to request it
+receives, and executes it.
 
 ### Models Package
 
-The `models` package contains the logic for mapping Python objects to their database representations. This involves an abstract `model` which has generic CRUD operations. Extensions of `model`, such as a `User` or `Project`, specify some more specific operations and their collection metadata.
+The `models` package contains the logic for mapping Python objects to their database representations. This involves an
+abstract `model` which has generic CRUD operations. Extensions of `model`, such as a `User` or `Project`, specify some
+more specific operations and their collection metadata.
 
 `Endpoint`s import these `models` and use them to execute requests.
 
 ## Setup for Local Development
 
-The following steps will guide you through setting up the OpenDC web server locally for development. To test individual endpoints, edit `static/index.html`.
+The following steps will guide you through setting up the OpenDC web server locally for development.
 
 ### Local Setup
 
 #### Install requirements
 
-Make sure you have Python 3.7+ installed (if not, get it [here](https://www.python.org/)), as well as pip (if not, get it [here](https://pip.pypa.io/en/stable/installing/)). Then run the following to install the requirements.
+Make sure you have Python 3.7+ installed (if not, get it [here](https://www.python.org/)), as well as pip (if not, get
+it [here](https://pip.pypa.io/en/stable/installing/)). Then run the following to install the requirements.
 
 ```bash
 pip install -r requirements.txt
 ```
 
-The web server also requires a running MongoDB instance. We recommend setting this up through docker, by running `docker-compose build` and `docker-compose up` in the [`mongodb` directory](../database) of the main OpenDC repository.
+The web server also requires a running MongoDB instance. We recommend setting this up through docker, by
+running `docker-compose build` and `docker-compose up` in the [`mongodb` directory](../../database) of the main OpenDC
+repository.
 
 #### Get and configure the code
 
-Clone OpenDC and follow the [instructions in the main repository](../) to set up a Google OAuth ID and environment variables.
+Clone OpenDC and follow the [instructions from the deployment guide](../../docs/deploy.md) to set up an [Auth0](https://auth0.com)
+application and environment variables.
 
 **Important:** Be sure to set up environment variables according to those instructions, in a `.env` file.
 
-If you want to test REST calls manually, add your own `OAUTH_CLIENT_ID` in `content=` on line `2` in `api/static/index.html`.
-
 #### Set up the database
 
-You can selectively run only the database services from the standard OpenDC `docker-compose` setup (in the root directory):
+You can selectively run only the database services from the standard OpenDC `docker-compose` setup (in the root
+directory):
 
 ```bash
 docker-compose build mongo mongo-express
 docker-compose up mongo mongo-express
 ```
 
-This will set you up with a running MongoDB instance and a visual inspection tool running on [localhost:8082](http://localhost:8082), with which you can view and manipulate the database. Add the simulator images to the command lists above if you want to test simulation capabilities, as well.
+This will set you up with a running MongoDB instance and a visual inspection tool running
+on [localhost:8082](http://localhost:8082), with which you can view and manipulate the database. Add the simulator
+images to the command lists above if you want to test simulation capabilities, as well.
 
 ### Local Development
 
 Run the server.
 
 ```bash
-cd api
-python main.py
+python3 -m flask run --port 8081
 ```
 
-When editing the web server code, restart the server (`CTRL` + `c` followed by `python main.py` in the console running the server) to see the result of your changes.
+When editing the web server code, restart the server (`CTRL` + `c` followed by `python app.py` in the console running
+the server) to see the result of your changes.
 
 #### Code Style
 
-To format all files, run `format.sh` in this directory. The script uses `yapf` internally to format everything automatically.
+To format all files, run `format.sh` in this directory. The script uses `yapf` internally to format everything
+automatically.
 
 To check if code style is up to modern standards, run `check.sh` in this directory. The script uses `pylint` internally.