Question 2. (40 pts)
We are going to start putting together a server that can register users with our site and allows
users to get information from our site. For testing we will allow the retrieval of all user names
“allNames”, and a particular users “nickname”. The server will be implemented with Express.js,
all interfaces will be JSON based (no HTML, templates or forms required). We will store and
retrieve the information from an NEDB document database. We will use requests to send and
retrieve JSON from the server.
(a) JSON Server and Database
Write a express based webserver that has a path “/register” that processes put methods containing
a JSON body of the form. {"name": "Jane Smith", "nickname": "Janey"} It will then put
that information into an NEDB database after it checks that the “name” is not already present. It
will send a JSON response in the form. {"registration": "succeeded"/"failed", "user":
"name", "reason": " nothing on success reason for failure"}
Show the code for this Express “view” here.
(b) Test the “/register” path
Write a short Node.js program based on requests to add five or more users to the database. It
should print out the response it receives from the server for each request. Show the code here.
Show the output from the first run of this program. Then run the program again to show that the
entries are already in the database and will not be added again. Put this “script” in a directory
called “test”.
(c) Add an “/allUsers” path and functionality
Add a *get" interface with path “/allUsers” that returns a JSON object of the following form.
{"date": "date string", "users": [array of all the user names but not
nicknames]}. You will create this JSON object by querying your NEDB database for all the
user names (but not the nicknames). Show the code for this “view” here.
(d) Test the “/allUsers” path
Write a short Node.js program based on requests to test the interface from part (c). Show your
code here and its output.
(e) Nickname interface
Add a get interface with path “/nickname” that sends a JSON body of the form. {"user":
"name of user"} and returns a JSON response of the form. {"user": "name", "nickname":
"users nickname"} if the user is in the database and a response of the form. {"user": "name",
"error": "Not Found"} if the user is not in the database. Show the code for this “view” here.
(f) Test the Nickname interface
Write a short Node.js program based on requests to test the interface from part (e) for two
existing users and one name not in the user database.
(g) Password Authentication
We are now going to harden our server from question 2 a bit. For each one of your test users we
will add a password. This will be presented to the “/register” interface along with the name and
nickname attributes. A fundamental rule for websites is to NEVER store passwords “in the clear”.
Instead we store a secure hash of password in the database on the server.
Update the /registration interface on the server to save a secure hash (use either argon2 or
bycryptjs for hashing) of the users password into the user database. Update your test script. to
include different passwords for each user. Show your modified “view” code and to prove to me
that you are not saving passwords in the clear show me what your user database looks like too.
(h) Restricting Access to Interfaces
Add “protection” to the /allUsers and /nickname views so that only registered users with valid
passwords can use these interfaces. You will need to add information on the user making the
request and their password. For /allUsers you will send a JSON message that looks like
{“Rname”: users-name, “Rpassword”: password-in-the-clear}. For the /nickname interface you
will send a request that looks like {"Rname": users-name, "Rpassword": password-in-
the-clear, "user": "name of user whose nickname you want"}. Where I’m using
“Rname” and “Rpassword” to denote the name and password of the user making the request.
Show the code for the modified /allUsers view, appropriately update your testing code and
show results for three different tests on the /nickname interface: (i) authenticated request with
user name in data base, (ii) authenticated request with user name not in data base, (iii) request
with invalid password or requestor name.
Question 3. (20 pts)
(a) The Cookies Path Attribute
In this question we are going to come up with a very simple example to illustrate what an HTTP
cookie’s path attribute does. For this we will write a simple server that will set three cookies
each with a different path attribute. One of the paths will be “/” you can make up names for the
other two paths. The server will handle get requests on all three paths. However on the “/” path
your server will set three cookies whose name and contents will be of your choosing and
whose path attribute will correspond to one of the three paths already mention. Write enough
code for each of the views so that you can see what cookies were received on the web page (see
examples below). Explain the behavior. you are seeing as far as which cookies get sent to which
pages.
(b) Cookies and the Request Library
Write a Node.js program using the request library to visit the three paths from the server in part
(a). Show the output from requests below. Are these results consistent with those in part (a) or
different? Explain? My output looked something like:
$ node SolBadCookiesRequest.js
Starting my web requests:
Path "/": "Testing cookies, I received: {}"
Path "/tide": "Testing cookies, tide path, I received: {}"
Path "/wind": "Testing cookies, wave path, I received: {}"
(c) Using Cookies with the Request Library
Visit the npm request documentation and modify your program so that cookies are saved
between request call (but not between script. runs). Show your output. I get something like this (I
modified the script. to go back to the “/” root path at the end):
$ node SolGoodCookiesRequest.js
Starting my web requests:
Path "/": "Testing cookies, I received: {}"
Path "/tide": "Testing cookies, tide path, I received:
{\"tideHeight\":\"Above 3
feet\",\"general\":\"Nice weather\"}"
Path "/wind": "Testing cookies, wave path, I received:
{\"windSpeed\":\"Around 2
0mph\",\"general\":\"Nice weather\"}"
Path "/": "Testing cookies, I received: {\"general\":\"Nice weather\"}"
Question 4. (10 pts)
In this question you will get hands on with session middleware and cookies. You will modify the
file expressSessionTest1.js per the instructions below.
(a) Changing the “session fingerprint”
Modify the expressSessionTest1.js code so that the name of the cookie corresponds to your
NetId. Demonstrate this by running the server code and pointing your browser at the “/” path.
Open up the devlopment panel and find the cookie. Take a screen shot showing the cookie set by
the middleware and the name you gave to it.
(b) Verify session ID changes on login
Verify that the session id changes when the user “logs in”. Show two screen shots one for before
the user logs in and one after. Have the cookie value showing in the developer panel. Find the
code that does this in the expressSessionTest1.js and paste it here.
(c) Show access restrictions
Without being “logged in” show that access is restricted to the “/wind” path, but not the “/wave”
path (show screen shots). Find the code that performs the access restriction on the “/wind” path
in expressSessionTest1.jsand paste it here.
(d) Deleting cookies
In expressSessionTest1.js I use the Express.js function res.clearCookie(cookieName,
options) to “logout” a user. What does Express.js actually do to the cookie? Capture the screen
shot of the cookie header sent in the “/logout” response to the browser (use the developer
network view) and explain what Express.js did. (Hint it does two things to essentially remove the
cookie from the browser.)