diff --git a/unit_02/w06d04/homework/README.md b/unit_02/w06d04/homework/README.md index a824643..035628f 100644 --- a/unit_02/w06d04/homework/README.md +++ b/unit_02/w06d04/homework/README.md @@ -2,28 +2,21 @@ WDI-Archer & WDI-Bowie #Homework -## Handling Sessions in Node +Copy your files and folder from Tuesday night's homework (that you worked on last night as well) into tonight's homework folder. You will be using the application that you made to work on tonight's homework. -The video associated with this gist is located [here](https://www.youtube.com/watch?v=C_Cb8-lsrn8). +Remember to run `bundle install` inside the folder that has been copied over so that node can reinstall all of the packages that you installed previously. Also remember to touch a .gitignore file and ignore node_modules. Do the following with this server: -## Concept Questions -1. What are cookies (not the food kind)? Where can you find them in the browser? -2. What is a 'session'? -3. What kind of options can we set on the express-sessions pacakge when we .use it? what is required? What does the secret do? -4. How do we access the session storage in node? -5. What kind of things can be stored in a sessions? -6. What kind of things do you think sessions will eventually allow us to implement? +## Handling Sessions in Node -## Exercises +1. *Middleware* Install and require `express-session`: for setting sessions and cookies. -Create a new express server and npm install and require everything you need (or use the one you made while following along the video if you had done so). Be sure to install express-sessions, body-parser, ejs, and mongoose. Also remember to touch a .gitignore file and ignore node_modules. Do the following with this server: +2. Create 2 new pages: a login page and a welcome page. The login page should have a form element that asks the user for a name. When the user submits the form, save it in sessions and make the welcome page display: "Welcome, `name`". Refresh the welcome page, does the name persist? -1. Create 2 pages: a welcome page and a form page. The form should ask the user for a name. When the user submits the form, save it in sessions and make the welcome page display: "Welcome, name". Refresh the welcome page, does the name persist? -2. Lets now use a database with stored information to populate our session. +3. Now let's use the database to store the information to populate our session. - Connect to mongo using mongoose - Create a mongoose schema for a user. Be sure to register it into a model. The schema should have a name (string) and color (also string) - - Change the form route for setting the user's name. Instead of setting it in sessions, Create a new user in your user collection. Add an input for the person's favorite color and store that along with the user's name. - - Create a new page for a login form. This form should take only a user's name. When a user submits, find there document in the database and set, in sessions, their name and color. + - Change the form route for setting the user's name. Instead of setting it in sessions, create a new user in your user collection. Add an input for the person's favorite color and store that along with the user's name. + - Now, when a user submits the login form, find their document in the database and set, in sessions, their name and color. - When a user goes to the welcome page, if they do not have a name set in sessions, redirect them to the login. If they have a name, render the welcome page with the normal welcome message and change the background to their color.
@@ -42,42 +35,10 @@ https://github.com/ajbraus/wdi-homework/blob/master/express-auth-bcrypt.md ## Authentication & Authorization -* **Authentication** verifies that a user is who they say they are. When a user logs into our site, we *authenticate* them by checking that the password they typed in matches the password we have stored for them. -* **Authorization** is the process of determining whether or not a user has *permission* to to perform certain actions on our site. For example, a user may *be authorized* to view their profile page and edit their own blog posts, but not to edit another user's blog posts. - -## Why do we hash (and salt) passwords? - -In order to authenticate a user, we need to store their password in our database. This allows us to check that the user typed in the correct password when logging into our site. - -The downside is that if anyone ever got access to our database, they would also have access to all of our users' login information. We use a hashing algorithm to avoid storing plain-text passwords in the database. We also use a salt to randomize the hashing algorithm, providing extra security against potential attacks. - -![](http://memeshare.net/memes/1/604.png) - -## Implementing Authentication - -To give users the ability to sign up and log in to our site, we'll need: - -* **Express:** for building our application and handling requests -* **Middleware:** - * `body-parser`: for handling incoming form data - * `express-session`: for setting sessions and cookies - * `connect-pg-simple`: connect sessions to pg - * -* **A users table in pg:** for CRUD-ing users and setting up authentication methods -* ** A sessions table:** set up by connect-pg-simple -* **bcrypt:** for hashing users' passwords +1. *Middleware:* Install and require `bcrypt`: for handling incoming form data ## Challenges: Part 1 - -**Goal:** Setup project from starter code. - -1. Pull from upstream, cd into the example application in classwork for today - -3. Create the appropriate database name and connection string in pg.js - -4. Create a users table that has an email and a password_digest (both strings) - - +4. Update the users schema so that it has an email and a password_digest (both strings) 6. Add a home route to `server.js` which renders `home.html.ejs` which has an anchor tag, signup that links to `/users/new` with text of `Signup`. 7. in the routes directory with a file users.js diff --git a/unit_02/w06d04/morning_exercise/README.md b/unit_02/w06d04/morning_exercise/README.md new file mode 100644 index 0000000..0b55f23 --- /dev/null +++ b/unit_02/w06d04/morning_exercise/README.md @@ -0,0 +1,16 @@ +## The Caesar Cipher + +From Wikipedia: + +> In cryptography, a Caesar cipher is one of the simplest and most widely known encryption techniques. It is a type of substitution cipher in which each letter in the plaintext is replaced by a letter some fixed number of positions down the alphabet. The method is named after Julius Caesar, who used it in his private correspondence. + +We're going to implement a simple Caesar Cipher called ROT13 ("rotate by 13 places"). The transformation can be represented by aligning two alphabets, like so: + +``` +Plain: abcdefghijklmnopqrstuvwxyz +Cipher: nopqrstuvwxyzabcdefghijklm +``` + +ROT13 is its own inverse; that is, to undo ROT13, the same algorithm is applied, so the same action can be used for encoding and decoding. The algorithm provides virtually no cryptographic security, and is often cited as a canonical example of weak encryption. ROT13 is used in online forums as a means of hiding spoilers, punchlines, and puzzle solutions from the casual glance. + +Write a method that will take a string as an input and encode / decode it using ROT13.