CAB230 Assignment 3, 2023 Server-Side Introduction In the 2nd assignment, you developed a React application that allowed users to view information about movies and the people who create them. The data was accessed from a REST API that we provided you. In this assignment, your task is to create the server hosting that same API (with a couple of small additions.) This assignment builds upon the lecture and practical material covered in the second half of CAB230. In particular, you must use the following technologies: • Node • Express • MySQL (or MariaDB) • Swagger • Knex • JSON Web Tokens No alternatives to these core technologies are permitted. An essential part of this assignment is to deploy your Express application to the provided virtual machine that we have allocated to you. Information on this was provided in Week 11. Although this assignment shares a lot in common with the second assignment, insofar as we are using the same movies dataset and working with a common API, your grade level in assignment two will have no bearing on your grade level for assignment three – so treat it as a clean slate! The Data The movies database is provided as a SQL dump in the assignment_data.zip file. You should import this database following a similar process to the “World Cities” database that we have been working on in the practicals. Once the dataset has been successfully imported, you should not touch it at all (except to add a table or tables for storing user details.) The database consists of the following tables: • basics – containing information about each film • crew – (not needed for this assignment) • names – contains information about people, used for the /people/{id} endpoint • principals – containing information about 10 of the main people that worked on the film • ratings – containing ratings from IMDB, Rotten Tomatoes and Metacritic • ratingsold – (not needed for this assignment) Open up the database in MySQL Workbench and look around to get a feel for the fields in the database and the types of values to be found in each. Note that some of these fields contain null values, usually because some information was missing or is not relevant. Note that we have not provided a table for storing user data – you will need to create this yourself. Additionally, note that advanced SQL knowledge is not required for any part of this assignment – it is not necessary to use JOINs, although you are permitted to use them. The REST API The API you are required to implement is identical to the one hosted at http://sefdb02.qut.edu.au:3001/, except with two additional endpoints that you also need to implement. These endpoints are for storing and retrieving profile information about the users. Rate-limiting It is not necessary for your assignment to support rate-limiting, or to produce 429 errors. If you do wish to implement rate-limiting, you can use express-rate-limit, but be warned – during automated testing we will hit your API with many requests very quickly. The profile routes You are required to, provide, in addition to the routes in the Assignment 2 API, two additional routes: GET /user/{email}/profile and PUT /user/{email}/profile. You need to implement these routes and add documentation to them to the Swagger file. GET /user/{email}/profile This route returns a user’s profile information as a JSON object. There are two different types of output presented here – one if the request is authorised, and the other if it is not. An unauthorised request (without an ‘Authorized:’ header) will receive an object like this: 200 OK { “email”: “[email protected]”, “firstName”: “Michael”, “lastName”: “Jordan” } The same request, but with a valid JWT bearer token, will receive an object like this, with additional fields for date of birth and address. 200 OK { “email”: “[email protected]”, “firstName”: “Michael”, “lastName”: “Jordan”, “dob”: “1963-02-17”, “address”: “123 Fake Street, Springfield” } The above two examples are of successful requests, which come with the HTTP status code of 200. However, if there is a problem with the JWT token, your server will return one of the following responses with a status code of 401 Unauthorized. ? If the JWT token has expired: 401 Unauthorized { “error”: true, “message”: “JWT token has expired” } If the JWT token failed verification: 401 Unauthorized { “error”: true, “message”: “Invalid JWT token” } If there was an ‘Authorization:’ header, but it did not contain ‘Bearer ‘ followed by the JWT: 401 Unauthorized { “error”: true, “message”: “Authorization header is malformed” } If {email} corresponds to a non-existent user, the following response will be returned with a status code of 404 Not Found: 404 Not Found { “error”: true, “message”: “User not found” } Note that a newly created user will not have any of these fields filled in. Your server will return null for any fields that have not been provided, e.g.: 200 OK { “email”: “[email protected]”, “firstName”: null, “lastName”: null, “dob”: null, “address”: null } PUT /user/{email}/profile This is used to provide profile information. The request will contain a body with the application/json content-type containing profile fields in the same format that they are returned with GET /user/{email}/profile (except without the email address): { “firstName”: “Michael”, “lastName”: “Jordan”, “dob”: “1963-02-17”, “address”: “123 Fake Street, Springfield” } Users can only change their own profile information. In other words, if you are logged in as [email protected], you can change the profile of [email protected], but not any other user. If you successfully update a profile, the response will be an object containing the updated profile: 200 OK { “email”: “[email protected]”, “firstName”: “Michael”, “lastName”: “Jordan”, “dob”: “1963-02-17”, “address”: “123 Fake Street, Springfield” } If the user is logged in with the wrong email (that is, the JWT is provided and is valid, but the credentials do not belong to the user whose profile the user is attempting to modify) your server will return the following: 403 Forbidden {