Assignment 5

Introduction

Having implemented both authentication and authorization, it is time to add additional functionality to both of these processes. In addition, with the ability to allow only authorized users into restricted areas, you will add the ability for employee or administrative users to edit and delete inventory items. Remember to add error handling to all new routes.

Video Demo

The video provides a general overview of the assignment, but follow the written steps to complete the activity. This is the Transcript of the video.

Tasks

Hint: carefully consult these resources jsonwebtoken , cookie-parser, and HTTP Cookies in Node and don't forget about the Express "locals" property while working on these tasks. This enhancement consists of multiple tasks:

Task 1

Change the header partial file so that when a client is logged in, the "My Account" link is hidden and a "Logout" link is displayed. When the client logs out, the "My Account" link is restored and the "Logout" link is hidden. Hidden, in this context, means it is not included in the view markup, not just hidden from view. If you were to look at the source code in the browser, the code would NOT be present. In addition, add another link (e.g. Welcome Basic) to the header partial, to the left of the link mentioned above, that allows the client to click it in order to navigate to the account management view. This should only be visible when the client is logged in.

Task 2

Use middleware that makes use of the JWT token and checks the account type, and only allows access to any of the inventory administrative views or processes that add/edit/delete items (classifications or vehicles) if the account type is "Employee" or "Admin". On failure, the login view should be delivered with appropriate message. This must NOT be used when delivering the classification or detail views as they are meant for site visitors who may not be logged in.

Task 3

Add functionality to the account management view:

• if the account type is "Client": greet the client by first name in an <h2> element (e.g. <h2>Welcome Basic</h2>).
• if the account type is "Employee" or "Admin": greet the client by first name in an <h2> element (e.g. <h2>Welcome Happy</h2>) and add another <h3> heading below the greeting that indicates "Inventory Management" and below it, a <p> element containing a link to access the Inventory Management view, via the MVC process.
• Make sure that if the account type is "Client", that the <h3> element and link to inventory management is not rendered at all in the view. This should be similar to the process used to display the "My Account" and "Logout" links in the header.
• Add an "update account information" link to the view, so a client can update their information. This link should be present for all clients. The link must pass through the accounts router and be handled by the accounts controller. The id of the logged-in client should be passed through the link.
• The update account link should appear above where the "Manage Inventory" heading is located.

Task 4

You will create a new view where clients can update their account data - first name, last name, email address and password:

1. Create a new update view in the views > account folder.
2. The view should contain the typical components for a view: Errors, Message, H1 using the same value as the title.
3. The view will also contain two forms: 1) "Account Update", consisting of the first and last names and email and 2) "Change Password" to change the password.
4. Ensure that the view is valid HTML when done and the forms are styled to meet form best practices.

Account Update Form

1. Add the first form and display the client's first name, last name and email address in an appropriate input field for editing. Be sure that each input has an accompanying label element.
2. Each of the three inputs must also be "sticky" if errors are returned from the controller during server-side validation.
3. All three fields are required, and all three must be checked using both client-side and server-side validation.
4. Add the account_id to a hidden field with an appropriate name - value pair.
5. Add an appropriate submit input for the account update.

Change Password Form

1. Add the second form, completely separate from the first.
2. Do NOT display the password in the input (it is a hash anyway and wouldn't make any sense) field.
3. Include a form input and accompanying label for entering a new password. Use the same validation for it as you did for the password field in the original registration form.
4. Provide information to the client to know that by entering a password it will change the current password and reminding them of the requirements for a password (length, characters, etc...).
5. Add the account_id in a hidden field with an appropriate name - value pair to the form.
6. Add an appropriate submit input for the password change.

Task 5

1. Add "get" and "post" route handlers to the account route file, to handle delivery of the account update view and to process the update of the account information as well as the password update request.
2. Implement server-side validation middleware for the update post handlers, including that the email address does not already exist if it is being changed, and that the password meets the stated requirements.
3. In the account controller, add a function to deliver the account update view.
4. In the account controller, add a function to handle the "account update" process, including:
   1. Return data to the update view for correction if errors are found.
   2. Set a success or failure message to inform the client.
   3. Query the account data from the database after the update is done.
   4. Deliver the management view where the updated account information will be displayed along with the success or failure message.
5. In the account controller, add a function to handle the "password change" process:
   1. If there is an error with the new password, set an error message and return to the update view to be fixed.
   2. If no error is found, the password must be hashed then sent to a function to be updated in the database.
   3. Determine the result of the update.
   4. Set a success or failure message to inform the client.
   5. Deliver the management view where the account information will be displayed along with the success or failure message.

The account model will need three new functions:

1. A function, similar to the function that was previously built to get account information based on the email address. However, this function will get the account information based on the account_id.
2. A function to handle the update of the account information as submitted to the controller from the account update form. It will only need to update the firstname, lastname and email values based on the account_id.
3. A third function to update the password (as a hash), based on the account_id. Be sure that after submitting the new password to check the account table to make sure the password is a hash as part of your testing.

Task 6

Add a logout process to the application that, when finished, deletes the token cookie and returns the client to the home view.

Test

Thoroughly test the functionality of each task to ensure it works as described in the development and production environments.

Submission

• Work with your learning team to accomplish the tasks and post to and read the collaboration tool to help one another.
• Build, run and test in your development environment to make sure each task works.
• When satisfied that the code is operational:
  1. Upload the project to your GitHub repository.
  2. Go to the render.com dashboard and manually deploy to your web service.
  3. Thoroughly test the application in the browser on the production server following deployment.
  4. Fix any and all errors prior to submission.
  5. Submit the render.com production URL AND the GitHub repository URL as a comment in the assignment submission.

Grading Matrix

This enhancement has values in multiple objectives as shown below:

Objective 1

• The account-management and account update views meets the standards found in the Frontend Checklist.
• Obj. 1 value: Refer to grade book

Objective 2

• The code in the header partial is fully operational to display the correct links based on the logged-in state of the client. This is true in all views, throughout the application.
• The greeting in the account-management view is accurate for the type of account logged in. Additionally, the <h2> element is not present in the view for the "Client" account_type, including not being visible in the source code viewable in the browser.
• Appropriate routes exist and work correctly to deliver the update view and process the updates.
• A function exists in the accounts controller and works correctly to process the account update.
• A function exists in the accounts controller and works correctly to process the password update.
• Obj. 2 value: Refer to grade book

Objective 3

• The middleware is applied correctly in the MVC model process of the application.
• The flow of the application is governed correctly by the middleware.
• All processes required in the assignment are done so using the MVC approach, and work correctly.
• Obj. 3 value: Refer to grade book

Objective 4

• A new function is present and operational in the accounts model to process the account update.
• A new function is present and operational in the accounts model to process the password update.
• A new function is present and operational in the accounts model to query account information based on a account_id.
• All functions use a parameterized statement approach to add protection to the database.
• Obj. 4 value: Refer to grade book

Objective 5

• Authentication works correctly.
• The JWT token is created correctly and passed back and forth between browser and server correctly.
• Middleware is used correctly to authorize the client to enter restricted areas.
• The token payload is used correctly to greet clients in the account-management view.
• Client data is checked using client-side and server-side validation and errors are returned to the view for correction.
• Password data is checked using client-side and server-side validation and errors are returned to the view for correction.
• The logout process works as required, including the cookie no longer being present after logout.
• Obj. 5 value: Refer to grade book

Objective 6

• The render.com production URL and the GitHub repository URL are both submitted on time and correctly. Both URL's must be present and operational for the assignment to be graded.
• Obj. 6 value: Refer to grade book