Our CRUD application was made by Pravin Modotholi, Iqbal Wan and Praveen Bandarage. It is a footwear shop. Currently hosted on Heroku - https://crud-project-nwen-304.herokuapp.com/

After cloning the repo, run npm install to download all of the packages and dependencies. Then run npm start to run the application.

npm install npm start

In terms of how to use the web application, first boot up the application on the browser if running locally. Locally the application runs on port 3000 hence the following link can be used to run the app in the browser - http://localhost:3000. Once booted any unauthenticated user will be presented with the index page which only displays products.

To view all features of the application, you should first register. To register a user you must click the sign up link from the nav bar or by performing a POST request for the /auth/register route. with your name, email and a password. The password must be of length 7 characters minimum, include at least 1 number, 1 capital lette and on special character.

If successful a redirect will be performed to the login page, where the user can now login.

To login simply enter a valid email and password on the login page, if an incorrect value is given then the page would populated with an alert depending on the error observed. If the login is successful will redirect back to the index page, where an extra add to Cart option will be visible below each product with an extra link to view the cart.

Authenticated users have the ability to add items to their cart as those protected routes are now open.

A user who is currently logged in is able to view all the products that they had added to their cart. In this page three actions can be perform; increase quantity, decrease quantity and remove product from cart. After decreasing if the quantity comes down to 0 then the product will be removed from the user’s cart.

Note - need to set a header with the a current authenticated user’s session ID. This value is assigned when a user logs in and the session related to the current user is saved on the database. To access that session to check for authentication a session ID must which is what’s stored in the cookie.

This function is only available to admin users, for testing an admin user with the credentials of test@mail.com (email) and password (password) can be used. Admin users will have two more links available in the nav bar. An add product and Edit product link. Admins can also add products to their shopping cart similar to authenticated users.

The add product page is just like any other form where you enter the details and the product will be added to the database. This form also allows the option to add an image with the product which will be saved locally on the server and the path of the image will be saved with the product in the database. API post request for adding a product: Note for this function a sID of an admin will be required.

This functionality can be accessed on the edit product page. This page contains a dropdown menu of all the products in the database. The user simply selects one to make changes on. Once selected the form values will get autofilled for edits to be performed as shown below.

All values can be edited and once complete the update button should be clicked. Note to perform this action the user will need to have admin rights.

Delete works in a similar fashion to update where the user selects a product from the dropdown and instead of clicking update the delete button is clicked. Both of the actions will provide visual feed whether it was successful or not.

As mentioned previously, the interface for our web application and REST API is a footwear shop which allows authenticated users to add products to their shopping cart and admin users to add shoes, view shoes, edit shoes, remove shoes and add shoes to cart. The REST API enables users to complete these functions and functions/requests for this can be viewed above.

With the web application, we provided thorough error handling as well as helpful tips to users whenever they encountered an error. For example during registration users will only see the register button once all fields have been filled out.

No registration button has been added. Similarly we provide feedback to the user based on the password they have provided and only show the registration button once it meets the specs of being of the specified length of 7, a numeric character and a special character. For example a valid password would be “password192@g” however “password2” would not be sufficient.

As I had already used praveenbandarage@gmail.com I encountered this error which told the user, the email was in fact already used.

For the login page similar visual feedback is displayed to the user when the request doesn’t meet the required criteria. Possible error include “incorrect email or password”, “password” is not allowed to be empty” and “email is not allowed to be empty”.

This was achieved by converting out validation function into middleware functions. This way the request will only proceed to the next middleware function once its successfully validated. This can be seen in our access management code section, which contains the code for registerValidation.

Throughout our web application and REST API we utilised similar error checking to provide users with feedback and responses when they had provided either an invalid input or were unauthorised. For example if a user attempts to remove a product that does not exist or a product which is not in their cat, they encounter a 400 error representing a client error.

Please refer to above CURL commands which can be used to test the frontend, which can also be done via POSTMAN.

The current database uses MongoDB. This is NoSQL

We have developed two databases to store our data “myFirstDatabase” and “shop.” They both store products, sessions and users. The difference is “myFirstDatabase” is a test database we used for our testing process whilst “shop” is our production database. Products as the name suggests, stores the name of the product, “Converse” for example, the price, a description of the product, a unique id (for selection/querying) and an image.

We used validation throughout our project to ensure that products meet our specifications. This was done primarily through the package mongoose as well as JOI. For our users and products model we used mongoose to declare the types, as well as set requirements for each aspect.

JOI was used for validation (middleware/dataValidation.js) to ensure that requests did meet the specifications when doing POST requests.

To connect to our database you must be authenticated, the DB connection code is

In regards to how to access the database, the DB is connected here and the driver for the database is in startup/database.js.

This is where we pass in the connection code which is stored in our .env file as well as connect to the database. Upon a successful connection a user will see a print statement in the terminal saying “Database connection successful.”

The user model contains the following properties:

• Name:
  • This property is just a string which is used to Identify the user by their name. Helps customize the web page and target each specific user.
• Email:
  • This property is used as the username as email tends to be unique, proves to be useful when trying to find the user from the database and serves as a better alternative compared to using the object ID.
• Password:
  • This property is used to authenticate a user and check if the account/information they are trying to access is actually theirs. Passwords are hashed using bcrypt before being saved in the database. For the required field a function is used which makes the password required if a local user is trying to create an account.
• type:
  • This property lets the server determine which type of user they are. Currently there can be two types of users: “local” and “google”. This property is used as we don’t have access to the passwords of google users. Hence every time a user logs in using google they will be authenticated against google users.
• Cart:
  • This property is an object array, where each object contains a reference to a product model and a quantity. This array is used to keep track of the products in each user's cart. Everytime a query is made for the user's cart, reference IDs get populated with the products in the database.
• date:
  • This property simply means the date at which the user registered into the server.
• isAdmin:
  • This property is used to distinguish admin users from normal customers, the property is a boolean value which is set to false by default on creation. All admin users will start off as normal users and in order to turn a user into an admin this property must be manually changed in from the database.

Testing GET requests to Login Page

loadtest http://localhost:3000/auth/login (with variations in RPS)

• @hapi/joi - for validation incoming request data
• bcryptjs - For hashing passwords
• connect-mongo -For saving users sessions on the database instead of server memory
• dotenv - Configuring/setting environment variables
• Ejs -Template engine and rendering web pages
• Express-session - Used to track user sessions
• Express - Server side framework to build api routes
• Mongoose - Object data modeling library for MongoDB
• mongoose-findOrCreate -A plugin function used during google oauth
• Multer - To parse multipart form data and handle incoming files on requests
• passport - Library used to build the authentication and authorization logic
• passport-google-Oauth-20 - Implement the google strategy and allow google logins
• Passport-local - Implement the local passport strategy and allow users to login in locally
• Chai - Assertion library used for testing
• Chai-http - To test api requests
• Mocha - Javascript test runner
• Mockgoose - Used to initialize Mock database
• Nodemon - Used for development to automatically restart server