WebFund 2016W Lecture 14

Video

The video for the lecture given on March 3, 2016 is now available.

Notes

In Class

Lecture 14
----------
* sessions
* jQuery


To do sessions securely, you need:
 (necessary but NOT sufficient)
* session cookies that cannot be guessed
  - use a secret
* secure password storage
  - need to be hashed at minimum
  - see bcrypt
* secure communication with web server
  - HTTPS (HTTP over SSL/TLS)
  

jQuery and client side JavaScript

jQuery is just a standard library for client-side JS
 - far from the only one

I could teach you the standard browser interface
 - but it is ugly and has quirks


How you build interfaces

code versus data

* when you build an interface, you have
  - code that determines the behavior
  - data that describes the interface appearance

* But code can change the appearance, and data can
  describe behavior

* how much do you do with each?

* traditionally, you do most everything with code

* When you want end-user customizability, you do more with data
  - theming

* Even when lots of the interface is in data, the code
  is in charge...except on the web

* On the web, the data is king, and the code serves the
  data

Student Notes

There are now fewer assignments. Assignments 5 and 6 are going to be bigger assignments since there are now less.
For the graph-demo tutorial, you could have hard coded the solution but the idea was to use loops to make things dynamic
- Each loops in Jade templates will be important for our next assignment
Today's goals:
- Sessions
- jQuery

Cookies and Sessions

Cookies

When logging in to the sample application shown in class:
- If you login on one tab, it won't let you login on another without logging out unless we use a private browser (the new tab appears as already logged in)
- If we login to different users on both the normal and private browser, then if we check to see who is logged in via either browser, it will tell us that both users are logged in
This is done using cookies
Cookies are small pieces of data sent from a website and stored in the user's web browser while the user is browsing. Every time the user loads the website, the browser sends the cookie back to the server to inform it of the user's previous activity
- More generally, cookies can be given to a client from any type of server. The client never does anything with the cookie aside from sending it back to the server during future interaction
Cookies are why the web browsers (normal and private) were logged in separately. Each had their own cookie from the server
- The normal and private browsers were seen by the server as different clients whereas two tabs from the same browser were seen as the same client so they used the same cookie
- If we remove the cookie you will not be logged in any more
Many cookies can be received just from visiting one website
- They are used by web servers for advertisement purposes
- There are also good cookies that let websites remember who you are so you do not have to constantly re-login every time you visit the website

Sessions

In the sample web application, we are using sessions to manage the cookies
In app.js we need to include:

var session = require('express-session');
app.use(session({secret: 'superSekretHere!',
		 resave: false,
		 saveUnitialized: false}));

The secret option is used to prevent people from stealing or guessing your secret. If you don't have a good secret people could reconstruct your cookies
In routes/index.js, we can see the use of a req.session object
- This object contains session information about the client that has sent in a request
We are using req.session.username to keep track of whether a user (a client) is logged in or not
- req.session.username at first has no value but once you submit a username (in the /login route), this value gets set
- Whether or not the value is set influences the behaviour of the web app
  - When it is set, we can no longer submit a username to log in but we can logout
  - This is because of the conditional statements in the route functions
    - In the / route, we render the index template (for logging in) if req.session.username is not set, otherwise we redirect to the /users route
    - Similarly, in the /users route, we render the users template if the values is set, otherwise, we redirect to the / route
Sessions are currently being stored in memory but the sessions should ideally be stored in a database
- To do this we use MongoDB (we will see this later)
To handle sessions securely, you need (necessary but NOT sufficient):
- Session cookies that cannot be guessed
  - Use a secret
- Secure password storage
  - Passwords need to be hashed at minimum
  - See bcrypt
- Secure communication with the web server
  - HTTPS (HTTP over SSL/TLS)

Client-Side JavaScript and jQuery

In the jQuery demo, we have an interactive interface that has nothing to do with the server and it is implemented with JavaScript
- This is run completely within the browser (there is not even a server running on the machine)
- When clicking on the favourite dog breed it automatically changes
- This is done through the use of client-side JavaScript and the jQuery library
jQuery is just a standard library for client side JavaScript and it is far from the only one
- We could learn the standard browser interface but it is ugly and has quirks
To include a client-side script on a web page, we need to add a script tag in the head of the HTML document which points to the right script
- In the demo, we have one to link the jQuery library and another to link our own client-side script (which uses jQuery)

Using jQuery

What is the "$" ?
- The "$" is equal to jQuery by default
The first thing that we do at the start of the script is give jQuery a callback function
- This callback function contains all of the other code in our demo client-side script and it will run when the page has fully loaded
- Because web browsers load things on a web page incrementally, we need this callback function to force the script to wait until everything is loaded
  - This ensures that we don't try to access something that is not there yet
We are primarily using jQuery to query things
- What are we querying?
  - The DOM (Document Object Model)
- Using the "#" is a way to tell jQuery that we are doing a query based on the ID of an element
- In order to allow for the demo script to easily access the favourite dog breed elements, they were given IDs in the HTML code
Once we have access to an HTML element, we can modify it however we want
jQuery is useful for making things nice and easy
- For example, it has a built in function for fading in and out elements
We can access the in-browser console through the dev tools which allows us to alter what we see on our webpage in real time (using a read-eval-print loop)
- For example, typing in $("#color").val("pink"); will set the value (in this case the text) of the element with ID "color" (in this case the text field) equal to "pink" so that "pink" will appear in the text field
Make sure to check the jQuery documentation for more details on how it works

Building Interfaces (Code Versus Data)

When you build an interface, you have
- Code that determines behavior
- Data that describes the interface appearance
But code can change the appearance, and data can describe behavior
- How much do you do with each?
  - Traditionally, you must do everything with code
  - When you want end-user customizability, you do more with data
    - Theming
  - Even when lots of the interface is in the data, the code is in charge... except on the web
- On the web, the data is king, and the code serves the data
  - The data (the HTML elements) completely define the interface
  - The code (client-side JavaScript) can be used to change things but ultimately we don't need this code