WebFund 2015W Lecture 14

Video

The video from the lecture given on March 2, 2015 is now available.

Notes

The persistent-notes application

Side note on modules with native code

What happens when our application has modules previously compiled for a platform different than the machine we are using now? We potentially get:

Error: “wrong ELF class: ELFCLASS32”

Application was expecting the 64-bit version of the mongo dB modules, but got the 32 bit. (There is a fallback so the application should still work fine)

Fix: Just use npm install to install the proper native mongodb module for your version of Linux.

Persistent session

Instead of storing sessions in memory, everything is now being stored in MongoDB. The set up for this can be seen in the following lines of code from app.js:

var MongoStore = require('connect-mongo')(session);

...

app.use(session({
   secret: "We need a better secret!",
   store: new MongoStore({url: 'mongodb://localhost/persistent-notes'}),
   resave: false,
   saveUninitialized: true
}));

Killing the server then restarting it will not cause the 'state' of the server to go away, because the 'state' of the server is not stored in memory, it is in the database. If a user is logged in to their account and you restart the server, when they reload the page you are on, they will still be logged in and their notes will remain.

In our database “persistent-notes” we now have a collection called “sessions” that stores session info. (i.e. cookies, username).

When a user logs out, their session gets destroyed. (Their set of notes still remains in the database and will not be lost.)

In index.js when a user logs out we call req.session.destroy(). This modifies the sessions collection in our database to indicate that the session is no longer valid. That’s how we destroy a session.

To remove all sessions simultaneously, we can call the drop() method for the sessions collection.

Persistent notes

Inside index.js, we now have a function connectToDBs() that we use to connect to our database and store a reference to the notes collection in our database (called notes) in a variable called notesCollection. We can then use MongoDB-specific methods of the variable to manipulate our collection.

In our update function we now update note objects differently. We start by setting the id using the ObjectID constructor loaded from the Mongo module. If the user is logged in, then we update the note object with matching id by setting its title and content to what we entered in the forms, then call checkUpdate() as a callback function. This can be seen in the following code:

var id = ObjectID(req.body.id);

...

if (username) {
   notesCollection.update({_id: id},
                          {$set: {title: noteTitle,
                                  content: content}},
                          checkUpdate);
}

Note: The $set operator ensures that only the specified fields have their values updated. (i.e. in the above code snippet we replace only the title and the content of the note, the owner will not be changed)

Related info

When opening another browser in private mode while already logged in, the other browser will not be logged in. We can then log in again. In this way, the same user can have more than one session simultaneously.

Web tracking: When in private browsing mode, your IP address and network connection are still the same, unless you use a proxy service, but even then people still can identify your IP address. Request headers are also still the same which give a lot of info away.

Client-side JavaScript

The biggest difference between server-side JavaScript and client-side JavaScript is that on the client-side, you have access to the DOM. The DOM is a representation of a web page as a tree with nodes that have data in them.

To run client-side JavaScript we can cause pages to load scripts by including them in the head of the page. In the Jade templates we have been working with, the header block can be used for this.

Why use client-side JavaScript?

You can modify a page without reloading it
You can use it to build better user interfaces with more functionality

What can't you do with client-side JavaScript?

It is SANDBOXED, i.e., functionality is limited. Client-side JavaScript is sandboxed as a security measure to isolate and control the effects of executing code on the client's machine.
No local file IO
Has to get data FROM THE NETWORK but only from certain parts of the network
Uses same origin policy => CSP

JQuery: A client-side JavaScript library which can be loaded along with a web page. Why is it called JQuery? Well it is a uniform interface for accessing (querying) the DOM.