CAB230 Web Computing Assignment
Assignment 2: Server Side
Release Date: May 14 2021 Submission Date: June 11 11:59PM [Friday of Week 14] Weighting: 45% of Unit Assessment Task: Individual Project
Introduction:
This assignment is a complement to assignment 1. In assignment 1, you built a React app to hit the API hosted on a QUT server. Your task here is to write and deploy an Express application that replicates and partially extends these services. This extended API will be made available at http://131.181.190.87:3002/, and the new endpoints will be included and documented in the Swagger at this site. We will discuss the requirements for the assignment in this document, but we will not at any stage present an API specification: you should rely solely on the Swagger for the finer details and to try it out in practice.
The basic technologies will be very similar to those you have seen in the server side pracs: • Node
• Express
• MySQL
• Swagger – source supplied except for the new routes.
• Knex, Helmet, Morgan, JWT and others
No alternatives to these core technologies are permitted, but as before you may use a range of additional packages to assist you.
Almost everything you need for this assignment can be adapted from the code you have written (or will write) for the server side pracs – including the JWT server-side worksheet. It is a requirement that you deploy your application to the Linux VMs we have provided within the QUT firewall, and so you must ultimately use the MySQL DB on your instance, though you are free to develop your code elsewhere and deploy later if you wish. You should initially develop your application to serve HTTP, and make the switch to (self-signed) HTTPS just before submission. Please see the relevant prac from Week 10 to guide you through this process.
The Data:
The World Happiness database will be provided as a standalone SQL dump file and you should follow the same process outlined in the pracs for the World Cities database to load it into MySQL. Once this dataset is in the database, you should not touch it at all. You will need to create an additional table to handle the user accounts – and ultimately deal with user profiles – but this is a separate issue, and the approach follows the description in the JWT Server Side
prac. You should work directly from that example, adapting and extending that code as needed to include appropriate responses.
The REST API:
The REST API endpoints are as documented in the Swagger docs discussed above, and you are required to implement them precisely as they appear at http://131.181.190.87:3002/. We will not rehash them here in any detail, and in any conflicts between what is written in this document and the Swagger API docs, the Swagger docs have absolute precedence. The additional routes – which relate to user profile information – will be considered below, though again, in any conflict, the Swagger docs are the authoritative source.
Staged Development:
The requirements for the server side of this assignment are fairly straightforward, but we strongly recommend that you follow the path laid out below. Note that you should follow the conventions used in the pracs and the worksheets in respect of the application architecture and application security, including middleware and handling of private information such as hashing of passwords. These details are in the pracs and worksheets from Week 7 through to Week 10. The code from these pracs will in general form a good starting point for your assignment work.
The steps you should follow are listed below:
Step 1: Create an Express App using Express Generator and establish the routes needed for the application without spending too much time on the application functionality. Work on localhost at this point. You may organise these routes as you see fit, but we expect to see sensible application structure and use of routers to handle related tasks. The basic indexRouter vs userRouter split imposed by Express will get you started. Applications in which all of the routes are handled from app.js will not be viewed favourably.
This assignment builds quite deliberately on the World DB REST API work that you have done in the pracs. Follow the same approach, and begin by using simple logging to ensure that the routes operate successfully.
Step 2: Having created an application and ensured that the routing is handled successfully, you should now replace these temporary logging statements with the requirements for each of the API endpoints. Most of the GET endpoints correspond to simple SELECT * queries in SQL and these are a good point to begin. It is sensible to proceed as follows:
• Implement the Data endpoints in their basic form, ignoring authentication.
• Implement the Users endpoints, ignoring JWT
• Implement the new Profile endpoints, again ignoring JWT
• Implement ‘authentication’ using a single dummy token to get the logic right
• Then add proper JWT token generation and handling and protect the authenticated routes.
• Most of the filtering is straightforward, but you might also want to add this in stages.
I have here glossed over a couple of complexities in the Profile routes. These are intended to be a bit of a step up from the pracs, and they may take you a bit longer than many of the others. But again, get the basics working and then add in the authorization code.
Step 3: Go through now and ensure that your endpoints have all of the responses covered. The Swagger docs show all of the appropriate codes that come back, and we have tried hard to show all of the appropriate error messages – see the instructions in the docs to find all of the responses. If you have the occasional incorrect error message, that is ok, but your response codes must match ours. We will test these extensively.
Step 4: At this stage, you should test your application using the tests that we will make available via a git repository (if you don’t know git you will be able to download a zip archive). These will appear sometime in Week 12. Note that these tests will all be based on the outward facing endpoints of your system. They will not be local or unit tests. The testing section of your final report will be based on this work and may consist solely of the automated output.
Step 5: Having created a working application deployed via HTTP, you should then migrate the application to serve HTTPS on localhost using a self-signed certificate. You should also deploy the app to the Linux VM we have provided for you. This is based on the prac from week 10. The running instance on the Linux VM will be the basis for subsequent demonstrations and marking.
Security and Logging:
We will require that you undertake an appropriate review of your application to limit its vulnerability… which is a very overblown way of saying that we expect some basic level of security as covered in the lectures and the pracs. At this level, the practical security features can be covered by a checklist, but we will also ask you to comment more extensively in the assignment report on the security of your application.
The key requirements are as follows:
• Use of knex or other query builder – there should be no raw SQL
• Use of helmet with at least the default settings enabled
• Use of morgan with a logging level similar to that used in the pracs.
• Appropriate handling of user passwords as described in the JWT Server-Side
worksheet – inappropriate storage and handling of passwords will be heavily
penalised.
• TLS/HTTPS deployment with a self-signed certificate
As noted above, migration to HTTPS may be undertaken just before submission.
The Additional Routes:
As noted above, Assignment 2 includes two new routes based on user profile information. These were not made available during Assignment 1. A basic description follows below, though once again your primary source lies in the Swagger at the API root. These routes are intended to be challenging and a step up from the work covered in the pracs.
The essential idea is that each registered user has the opportunity to provide profile information. Some of this is publicly available and some of it is not.
The fields are as shown in the Swagger example below:
In a real application we would include all sorts of information that might help us monetise the site, and we would have an admin user role with broad access to the personal information of the members. Both of those have been ignored in order to keep things a bit simpler.
The key points are as follows:
• User profile information is comprised of two components; public and authenticated.
Public fields are email, firstName and lastName. Authenticated fields of dob and address can only be accessed by the profile owner.
• As an authenticated user, if you attempt to access the profile of another user, the GET will work, but you will only see their public profile.
• Updating a user profile is restricted to the owner of that profile. Attempting to edit the profile of another user will result in an error 403 Forbidden.
Finally, there is one technical issue to watch – be careful of the date format, which follows the ISO 8061 format – see the Swagger for examples.
Grade Standards:
Broadly speaking, grade standards for the server side of the assignment will correspond to the feature levels laid out below, and there is a reasonable alignment with the development steps outlined above. Mostly the lower grades correspond to the easy endpoints. The higher grades require that you successfully implement authentication, authorisation and filtering, and that the profile routes follow the rules we have laid out. We also expect that you will follow a professional approach in the architecture and construction of the server. In particular, you should demonstrate that:
• The routes and the overall architecture are professional – logical and uncluttered, with appropriate use of specific routers mounted on the application
• There is appropriate use of middleware for managing components such as database connectivity and security
• There is appropriate error handling and responses match those in the API spec
• The application is successfully deployed using HTTPS
• There is an appropriate attention to application security
• The application successfully serves accurate Swagger docs on the home page route
All of these requirements must be met in order to achieve the highest grade levels.
As with the client-side assignment, you should understand that the grade levels discussed below assume that the feature levels required have been implemented competently. As always, if the implementation is substandard, then the marks will go down, sometimes substantially. It is more than possible to get a 4 level mark by doing a bad job of a 5 level requirement. Similarly, if you do a bad job of the 4 level requirement, then you are likely to get a 3 level mark. The precise mark necessarily depends on the mix of features successfully implemented, and the grade levels below are intended as a guide.
After taking note of all of these warnings and exceptions, the passing levels are as follows:
• [Grade of 4 level]: Successful deployment of an Express based API which supports some of the endpoints and interacts successfully with the database. Most likely people will complete the basic Data routes, but may not have proper filtering or completed
Authentication routes, or have managed to authorize the factors route. Swagger docs
may not be deployed, and there may be significant gaps in the security requirements.
• [Grade of 5 level]: Successful implementation of all of the Data endpoints at a basic level. Filtering should basically work, even if the factors route is not properly authorised. Registration and login and JWT token handling must be attempted, though there may be issues with the authentication. Some reasonable attempt must also be made at the Profile routes, though again there may be significant limitations at this level, especially in respect of authorization. At the grade of 4 or 5 level there may be
a number of incorrect responses and codes even if the basic application works.
• [Grade of 6 or 7 level]: The grade of 6 and 7 levels require successful completion of all of the routes. In particular, the Profile routes must work properly in both Authorized and Unauthorized modes at the 7 level. The distinction between 6 and 7 level grades for functionality then relates to problems in the valid and error responses on the routes, and in the successful use of middleware security, database connectivity and deployment of the Swagger docs. There is no ‘killer’ requirement here that makes the difference between a 6 and a 7. These requirements are best seen as a set that go together, and done very well, give you a 7 standard mark. If you miss some of them,
Submission
but still do a good job of the others, then you are likely to get a 6 standard mark.
We will provide clear instructions on deployment and submission closer to deadline. We will certainly be connecting to your machine on the QUT local network and so it will be necessary to ensure that your server remains running during the marking period.
As with the client-side assignment, we will expect a short report, generally running to around 10 pages or so, including screenshots. We will again provide a template and guide, but your report must include the following sections:
1. Introduction – telling us what was implemented and what wasn’t.
2. Technical description of the application. This section is to allow you to talk about the application architecture and middleware choices, and to discuss technical issues that caused you problems. This is especially important if something doesn’t actually work.
3. Security – a brief discussion of the security features of your application and a longer reflection on its limitations. We will provide more guidance on this in the report
template, but this will attract a significant fraction of the report marks.
4. Testing and limitations – test results as discussed above.
5. References
6. Appendix: a brief installation guide.
The CRA rubric will be released as a separate file.