CS 351 Fall 2019 Homework 9

Cookies, Sessions, Databases

Dr. Greg M. Bernstein

Due Wednesday, November 13th, 2019 by 11:59PM, 50 points.

General Instructions

Cookies, sessions, and databases.

Create and Use a new Branch hw9

We will create a new git branch called hw9 for use in this assignment. The branch you create must exactly match the one I’ve given you for you to receive any credit for this homework.

Prior to creating this new branch make sure your working directory is “clean”, i.e., consistent with the last commit you did when you turned in homework 8. Follow the procedures in GitHub for Classroom Use to create the new branch, i.e., git checkout -b hw9. Review the section on submission for using push with a new branch.

Use tourServer Directory

Use your tourServer from the previous homework and make sure it is at the top level of your repository.

Use README.md for Answers

You will modify the README.md file to contain the answers to this homework.

Questions

Question 1. (10 pts) Databases

We now want to upgrade our site to work with persistent data via the NEDB document oriented database. We will create initial databases from JSON files. As part of testing we will want to reset these databases, hence I first delete all existing database entries then add entries from the JSON data. A nice simple approach using the nedb-promises library looks something like:

(a) Initialize a users database

Write and run code to initialize a user database. Show your code here.

(b) Initialize a tours database

Write and run code to initialize a tours database. Show your code here.

Question 2. (10 pts) Updating Interfaces

(a) Update /tours interface

Now use the tours database to get the tours and pass to the tours template. Show updated handler code here (not the entire program).

(b) Update /addTours interface

Now you will add to the tours database. Show updated POST handler code here.

(d) Test /addTours

Add some tours. Stop the server. Restart the server. Make sure the added tours still show up.

Question 3. (10 pts) Sessions/Login

(a) Add express-session to your tourServer

Modify the SessionID cookie name to have it start with your NetID, and also modify cookie signing secret. Create session state initialization middleware code with initial session state session.user = {role: "guest"}. Hints: see course slides, don’t forget express-session installation. Show additional code you added to your server for sessions here.

(b) Test Session Cookies

To verify that sessions are working visit your site and take a screenshot showing one of your pages along with the cookie the session middleware sent to the browser. My screenshot looks like:

Screenshot with cookie
Screenshot with cookie

(c) Create login template

Create a login template that uses a POST form to send email and password to the server. Make sure to put a “login” link in your page navigation. Show your template code here:

(d) Create a “login error” template

Create a super simple template to tell them they have a login error. Show template code here.

Question 4. (10 pts) More Sessions/Login

(a) Create a “welcome” template

Create a super simple template to greet a logged in user by name. Show template code here.

(b) Process login

You will look up the user in the user database, and verify (or not) and update the session state per the course slides and example. Show POST login processing code here.

(c) Test login functionality

Show screenshots with cookies visible. Show successful login and bad login attempt. My screenshots look like:

Question 5. (10 pts) Protect Pages and Interfaces

(a) Role Based Rendering

Currently, we show all pages and all links to every visitor regardless of their role. This needs to be changed. We will now pass user information with every template rendering so that our base template can control the links a user can see. Update all your render calls to also pass user (from the session) information to the template. Show code here of how you updated your /tours handler.

(b) Modify Base Template 1

Add a <footer> element to show the users name at the bottom of each page (this will allow you to check that you are passing user information correctly with each template render). Show your modification here (not the whole template). A screenshot of the bottom of my tours page looks like this now:

(c) Modify Base Template 2

In your template conditionally render the “add tours” navigation item so that only “admin” users can see it. Show this modification here (not the entire template).

(d) Create a “Forbidden” Template

Create a super simple “Forbidden” template for use if somehow a user tries to do something non-authorized. Show your template here.

(e) Create and Insert Protection Middleware

Create middleware that checks for the “admin” role and if it doesn’t find it renders the “Forbidden” template. Add that middleware to both GET and POST handlers for adding tours. Show the code for that middleware here. When one of my “customer” users tries to navigate to the /addTours interface they get:

While an “admin” user will see: