COMP 2406 2024F Assignment 4 Solutions

GRADING NOTE: If a description of the development process or issues encountered is omitted, at least half the points of the question are deducted.


1. [2] Where in authdemo2 is the number of submission questions hardcoded? How does this compare to previous versions of this application?

A: The number of questions is hardcoded in static/validator-core.js, in the constant expectedQuestionList. In previous versions, the number of questions was also implicitly hardcoded in expectedQuestionList, but it was also hard coded in numerous places in the server-side code, especially any parts dealing with the database.

(1 for expectedQuestionList, 1 for previous version description)


2. [2] What is the format of the submission data uploaded to the server? Be precise, and explain how you confirmed your answer was correct.

A: The submission data is uploaded as a JSON object with two fields: filename and filecontents, which contain the uploaded file's filename and file contents, respectively.

We can see this on line 86 of static/student/validator.js, in doUploadSubmission(). We can also see in line 175 of authdemo2, where the call to checkSubmission passes in two fields from the submitted object.

To further verify, you can either make the client or server print this data to the console and/or you can use the browser network inspector to see the data passed to the server by the POST /uploadSubmission.

(1 for the JSON description, 1 for verification)


3. [2] What happens when a user uploads more than one submission? What new code (relative to past versions) is responsible for this behavior?

A: When a user uploads more than one submission, the newer submission replaces the old one. The replacement is then performed by the "INSERT OR REPLACE" (rather than "INSERT") when inserting the submission in db.addSubmission() (line 62 of authdb.js).

Note that while a uniqueness constraint is enforced by UNIQUE constraint on the studentID field in the code creating the submissionTable table (line 35), this isn't needed to make sure new submissions replace old ones, it just makes sure we don't ever have more than one submission with the same studentID.

(1 for description of what happens, 1 for identifying INSERT OR REPLACE)


4. [2] Does authdemo2 allow users to upload invalid submissions? If so, will such invalid submissions be stored in the server's database? Explain briefly.

A: authdemo2 does allow invalid submissions to be uploaded, because the validating and uploading are not directly connected. If we look at lines 30-33 of static/student/validator.js, we see the following code:

        var q = validateSubmission(fn, content);
        if (upload) {
            doUploadSubmission(fn, content);
        }

Note that the upload decision is just made on the basis of the upload variable (which is passed into the function). The result of calling validateSubmission, q, is ignored and not used in the function.

If we changed line 31 to be "if (q && upload)" then the upload would only happen if validateSubmission() succeeded.

(1 for yes, 1 for the explanation indicating the validation result doesn't influence the upload call)


5. [2] How could you change the analysis page of authdemo2 so it reports the number of empty answers for each question, and do so with minimal code changes?

A: Note that db.analyzeSubmissions() already calculates the blank questions (by calling calcBlankQuestionStats()), with the results included in the blankQuestions array (which are in the order of questions in expecteQuestionList). Thus all we need to do is report this information in showAnalysis().

We can update showAnalysis() in authdemo2.js with the following declaration at the top of the function:

   var blankQuestionList = makeBlankQuestionList(analysis.blankQuestions);

And then we add the following to the analysisBody template, say after the student ID list:

    <p>Blank Questions:
      <ol>
       ${blankQuestionList}
      </ol>
    </p>

We can then define makeBlankQuestionList() as follows:

function makeBlankQuestionList(blankQuestions) {
    const questions = expectedQuestionList.split(",");
    var r = [];
    
    for (let i=0; i < questions.length; i++) {
	let v = "<li> Q" + questions[i] + ": " + blankQuestions[i] + "</li>";
	r.push(v);
    }

    return r.join("\n");
}

(1 for identifying that the code already calculates the blanks, 1 for the code to display this information)


6. [2] By looking at the accounts table, can you easily tell if two users chose the same password in authdemo2? How do you know?

A: You cannot tell, because the password hashes are salted, meaning that the same password will never hash to the same value because a random string is combined with the password before hashing. We can verify this by creating two user accounts with the same password and then inspecting the contents of the accounts table, say by typing the following at the command shell (where we run deno):

  sqlite3 submissions.db "select * from accounts;"

These two accounts have the same passwords but observe that their hashes are different (the second field, after the username):

soma|$argon2id$v=19$m=19456,t=2,p=1$Rep3OHx6lg8$BLWQbOeIQOnpWSLfzvDzkWS6tuVM0McvrQ4E6mRedjM|admin|100|Anil Admin
anilsomayaji|$argon2id$v=19$m=19456,t=2,p=1$3pggZMTwXVCBILJt6DMdiSadM/5djeU5aYQQ1Q$NlAm1gopX2PRLJdGLMb8GVK/8n7hDwNFpf410xr/61M|student|771572|Anil Somayaji

For more information on salting, see:

  https://en.wikipedia.org/wiki/Salt_%28cryptography%29

(1 for saying no, 1 for explanation)


7. [3] [[WebFund 2024F Tutorial 8|Tutorial 8]]'s authdemo stored the logged in user's username in a cookie. What does authdemo2 store in a cookie to indicate that a user is logged in? In what way is this solution better? How is it worse?

A: Instead of a username, authdemo2 instead stores a uuid (basically, a random number) as a session identifier.

This solution is better in that it allows the cookie to expire, minimizing the risks of cookie theft. It also allows the server to keep track of different user sessions which may have different state associated with them.

This solution is worse in that now the server must maintain state for every user session, increasing the storage requirements of the server and, if the server is distributed, it must maintain this state across all servers.

(1 for uuid, 1  for better, 1 for worse)


8. [2] How long are sessions valid for in authdemo2? How could you change this so sessions last for 10 minutes?

A: Sessions are 3600 * 72 * 1000 milliseconds, or 3 days (72 hours). This value is specified on line 20 of authdb.js, the constant sessionLength.

To change it to 10 minutes, we just change the value of sessionLength to be 10 * 60 * 1000 (600,000 milliseconds).

(0.5 for 72 hours, 1 for sessionLength, 0.5 for 600,000 milliseconds)


9. [3] How could you change authdemo2 so it stored the uploading filename and file contents in its database? Be sure to specify what functionality was already present and what you had to add.

A: Since the client already uploads the file name and file contents to the server (as we saw in Question 2) and checkSubmission() already adds the filename and filecontents to the returned object (see lines 48 and 49 of static/validator-core.js), we just need to store this information server side.

First, we need to change the database schema to add two new fields to the submissions table, filename and filecontents. For that, we modify how submissionTable is created in authdb.js (around line 32):

db.execute(`
  CREATE TABLE IF NOT EXISTS ${submissionTable} (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    studentID TEXT UNIQUE,
    ${createQFields},
    filename TEXT,
    filecontents TEXT
  )
`);

If we wish to keep our existing accounts table we can run the following to get rid of the submissions table (assign4 in this case):

   sqlite3 submissions.db "drop table assign4"

We then need to change the SQL statement in db.addSubmission() to include the two new fields:

    return db.query(`INSERT OR REPLACE INTO ${submissionTable} ` +
                    "(studentID, filename, filecontents, " + queryQFields +
                    ") VALUES " + queryBlanks(numQuestions + 3), 
                    [r.studentID, r.filename, r.filecontents].concat(answers)
		   );

That's it!

(1 for recognizing existing functionality, 1 for table creation, 1 for addSubmission change)