Merge branch 'master' into cookiesAndCaching

Author: MohamedOmarii

week-5/streamsAndBuffers/.gitignore

@@ -0,0 +1 @@
+node_modules

week-5/streamsAndBuffers/illiad.txt

@@ -0,0 +1,5 @@
+hello
+my
+name
+is
+this

week-5/streamsAndBuffers/mobydick.txt

@@ -0,0 +1,14 @@
+{
+  "name": "streams-and-buffers",
+  "version": "1.0.0",
+  "description": "Learn about streams",
+  "main": "readStr.js",
+  "scripts": {
+    "test": "echo \"Error: no test specified\" && exit 1"
+  },
+  "author": "Mavis and Jack",
+  "license": "ISC",
+  "devDependencies": {
+    "split": "^1.0.0"
+  }
+}

week-5/streamsAndBuffers/out.txt

@@ -0,0 +1,47 @@
+const fs = require('fs');
+
+//Need to require this to split by lines
+const split = require('split');
+
+// our programm can take three flags, which are then assigned below, or default with the OR operator:
+var filepath = process.argv[2]||'./test.txt'
+var hwm = process.argv[3] || 100
+var timeout = process.argv[4] || 500
+
+// Create the readable stream of the filepath specified and the hwm and set the econding to utf8
+var file = fs.createReadStream(filepath, {highWaterMark:hwm, encoding: 'utf8'});
+
+//creat empty data
+var data =''
+
+//You pipe the readable stream into split which sends it back as chunks split by a new line
+file.pipe(split())
+
+//listen for error event
+file.on('error', function(err) {
+  console.log('Error '+err);
+  return err
+});
+
+//listen for data events
+file.on('data', function(bits) {
+
+  //add new bits to the data str
+  data +=bits
+
+  //print the new bit as a string (it comes buffered)
+  process.stdout.write(bits);
+
+  //pause the reading
+  file.pause();
+
+  //set a timeout as specified by the flag (def: 500ms) to then resume the read
+  setTimeout(() => {
+    file.resume();
+  }, timeout);
+})
+
+// listen for the end event
+file.on('end', function(){
+  console.log('Finished reading all of the data');
+});

week-5/streamsAndBuffers/package.json

@@ -0,0 +1,60 @@
+# Streams & Buffers
+
+### 1) Streams
+
+#### Data Access in Node
+-  Fully buffered access vs. partially buffered access - these differ in terms of:
+  - How the data is exposed
+  - The amount of memory used to store the data
+
+#### Fully Buffered Access
+- Asynchronous `readFile()`
+- Synchronous `readFileSync()`
+- The data is returned in **one big chunk** after all of it has been read
+- Node needs to allocate enough memory to store all of that data
+
+#### Partially Buffered Access
+- Asynchronous `read()` `createReadStream()`
+- Synchronous `readSync()`
+- Data input is treated as a **series of events**, occurring as the data is being read or written - this allows us to **access data as it is being read**
+- Partially-buffered methods (listed above) allow us to specify the size of the buffer and read the data in small chunks
+
+#### Streams
+- Streams are a form of **partially buffered access**
+- Streams return small pieces of data (using a buffer) and trigger an event when each new piece of data is available for processing
+- Since streams are partially buffered, we can process each piece of data **as soon as it is read** - this means we don't necessarily need to buffer / save the whole file into memory
+- The Node stream interface consists of two parts:
+  - Readable streams
+  - Writeable streams
+
+#### Readable Streams
+- Readable streams emit the following events:
+  - `data` emits a buffer / string
+  - `end` is emitted when the stream receives an EOF (End of Function) - this indicates that there will be no more `data` events
+  - `error` is emitted if there's an error receiving data
+- To bind a callback to an event, use `stream.on(eventname, callback)` - the HTTP request object is one example of a readable stream that we've already covered:
+  - `request.on('error', function(err) { ... });`
+  - `request.on('data', function(data) { ... });`
+  - `request.on('end', function() { ... });`
+- Readable streams also have the following methods:
+  - `request.pause()` pauses incoming data events
+  - `request.resume()` resumes after a `pause()`
+  - `request.destroy()` stops the stream emitting any more events
+
+### 2) Buffers
+- In Node, buffers are a **high-performance alternative** to strings, representing raw C memory allocation
+- Buffers act like fixed-size arrays of integers, each represented as a **hexidecimal number** when run through `console.log()`
+
+```js
+var buffer = new Buffer(10);
+buffer[0] = 255;
+console.log(buffer); // <Buffer ff 00 00 00 00 4a 00 00 00 00>
+```
+- Since buffers represent raw memory, any buffer content you haven't assigned (anything other than `buffer[0]` in the above example) will be whatever happens to sit in that position in memory (e.g. the `4a` seen above)
+- Compared to strings, buffers are fixed in size, and have very limited predefined functions (missing convenient ones like `String.replace()` for example)
+- If you want to use string functions on buffers, you can convert them to strings with `buffer.toString()` first
+
+## Resources
+- http://book.mixu.net/node/ch9.html
+- https://www.sitepoint.com/basics-node-js-streams/
+- https://www.tutorialspoint.com/nodejs/nodejs_streams.htm

week-5/streamsAndBuffers/readStr.js

@@ -0,0 +1,29 @@
+this is just a test of this line repeated a lotx1
+this is just a test of this line repeated a lotx2
+this is just a test of this line repeated a lotx3
+this is just a test of this line repeated a lotx4
+this is just a test of this line repeated a lotx5
+this is just a test of this line repeated a lotx6
+this is just a test of this line repeated a lotx7
+this is just a test of this line repeated a lotx8
+this is just a test of this line repeated a lotx9
+this is just a test of this line repeated a lotx10
+this is just a test of this line repeated a lotx11
+this is just a test of this line repeated a lotx12
+this is just a test of this line repeated a lotx13
+this is just a test of this line repeated a lotx14
+this is just a test of this line repeated a lotx15
+this is just a test of this line repeated a lotx16
+this is just a test of this line repeated a lotx17
+this is just a test of this line repeated a lotx18
+this is just a test of this line repeated a lotx19
+this is just a test of this line repeated a lotx20
+this is just a test of this line repeated a lotx21
+this is just a test of this line repeated a lotx22
+this is just a test of this line repeated a lotx23
+this is just a test of this line repeated a lotx24
+this is just a test of this line repeated a lotx25
+this is just a test of this line repeated a lotx26
+this is just a test of this line repeated a lotx27
+this is just a test of this line repeated a lotx28
+this is just a test of this line repeated a lotx29

week-5/streamsAndBuffers/streams-buffers.md

@@ -0,0 +1,21 @@
+//Require the file system module
+var fs = require('fs');
+
+
+//Create a writeable stream (i.e. a stream we can write to, which will go to ./out.txt)
+var file = fs.createWriteStream('./out.txt');
+
+//Process.stdin (opposite of process.stdout) is a readable stream, that reads data that we input into the terminal
+
+//So here when we read data from process.stdin.on we write that data to our file, the writable stream we created
+process.stdin.on('data', function(data) {
+  file.write(data);
+});
+
+//When the readable stream ends, we close the writeable stream
+process.stdin.on('end', function() {
+  file.end();
+});
+
+//Resume the incoming data stream after a pause
+process.stdin.resume();

week-5/streamsAndBuffers/test.txt

@@ -0,0 +1 @@
+[Click here for README](https://github.com/FACN1/research/blob/master/week-7/authentication/authentication.md)

week-5/streamsAndBuffers/writeStr.js

@@ -5,16 +5,39 @@ In the realm of the web,
 authentication is **the process of verifying the identity an individual, usually using a password.**
 
 ## Hashing
-What is it and why is it useful?
-
-
 ### Hashing a password
 
-![password_hash](https://github.com/FACN1/research/blob/master/week-7/authentication/password_hash.gif "Password hashing")
+![password_hash](https://github.com/FACN1/research/raw/master/week-7/authentication/password_hash.gif)
 
 ### Checking the password:
 
-![password_check](https://github.com/FACN1/research/blob/master/week-7/authentication/password_check.gif "Password check")
+![password_check](https://github.com/FACN1/research/raw/master/week-7/authentication/password_check.gif) "Password check"
+
+### What is it?
+- A hash function will take an input of any size, and give an output of fixed size, which is like a fingerprint. It should be mathematically irreversible (can't get a password from a hash). Theoretically, the chance of a hash collision (two inputs/passwords with the same output/hash) is very small, so two outputs of a hash function can be compared to determine if two files or strings are identical.
+
+**Types of hash**
+- A cryptographic hash, such as md5, SHA-1, SHA-256, etc is designed to be as fast as possible.
+- However, a password hash (such as bcrypt, PBKDF2) is designed to take as long as possible.
+  - This also means that password hashing should always be run asynchronously.
+
+**Salting**
+
+- While hashing functions are one-way (can't be reversed), crackers can have pre-calculated enormous amounts of input/output pairs - these are called rainbow tables.
+- a salt is generally a random string of characters to add complexity
+- bcrypt generates a unique salt for each user, and adds this salt
+
+### Why is it useful?
+
+- If a database is hacked (which should always be assumed - data breaches happen all the time), then if passwords are stored in plaintext, crackers can publish all the passwords on the internet, and anyone can try using the same passwords on other websites that the user uses, such as emails.
+  - However, if passwords are sufficiently hashed, and sensitive data such as credit card details is well encrypted, then the data is less useful for crackers. 
+
+**Compute Time**
+- The longer it takes to calculate the hash of a password, the better. This is because if a database is compromised, a cracker will try to brute force passwords to get the original password.
+- A cryptographic hash such as SHA-1 can be tried 10,000s of times a second or more; however, if bcrypt is used, only a few passwords could be tested each second (assuming a normal computer is used for brute forcing)
+
+
+
 
 
 ## Example
@@ -32,3 +55,4 @@ hapi-auth-basic:
 - Is outdated as it uses a pop-up to request username and password
 
 ## Links
+- [Brian Krebs article on Password Security](https://krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-security/)

week-7/authentication.md

@@ -33,16 +33,19 @@ const users = {
   }
 }
 // Create hashed passwords of 'password'. First arg 'user-pword' Second 'Salting rounds'
-console.log(bcrypt.hashSync('password', 0))
-console.log(bcrypt.hashSync('password', 0))
-
 console.log(bcrypt.hashSync('password', 1))
 console.log(bcrypt.hashSync('password', 1))
 
+// Creates the same passwords because using same salt
+bcrypt.genSalt(5, function(err, salt){
+  console.log(bcrypt.hashSync('password', salt))
+  console.log(bcrypt.hashSync('password', salt))
+})
+
 // Find out how many rounds of hashing were used to produce hashed password
 console.log(bcrypt.getRounds('$2a$10$iqJSHD.BGr0E2IxQwYgJmeP3NvhPrXAeLSaGCj6IR/XU5QtjVu5Tm'))
 
-// Bad easily crackable hashing function
+// Create bad easily crackable hashing function
 String.prototype.hashCode = function(){
     var hash = 0;
     if (this.length == 0) return hash;
@@ -93,3 +96,4 @@ server.register(basic, (err) => {
     console.log(`Server running on port: ${server.info.uri}`)
   })
 })
+

week-7/authentication/authentication.md

@@ -0,0 +1,68 @@
+# The Joi of Validation with Hapi
+
+### WHY?
+Its important to check data being inputted into your programme. Invalid data can throw errors, which are better caught as soon as possible, rather than after they've crashed your server!
+
+### WHAT?
+Joi is a hapi module which checks the payloads of requests and responses going in and out of a server.
+
+Joi allows you to create blueprints or schemas for javascript objects to ensure validation of key information.
+
+By default, all validators are set to ```true```, which means no validation is being performed, and everything passes through unchecked.
+
+
+### HOW?
+
+Install and require ```hapi``` and ```joi ``` into your server file.
+
+In your route, in addition to your method, path and handler, you can set validation parameters in the ```config``` object on a route, and is able to validate headers, path parameters, query parameters, and payload data.
+
+``` js
+
+server.route({
+    method: 'GET',
+    path: '/hello/{name}',
+    handler: function (request, reply) {
+        reply('Hello ' + request.params.name + '!');
+    },
+    config: {
+        validate: {
+            params: {
+                name: Joi.string().min(3).max(10)
+            }
+        }
+    }
+});
+```
+
+Example using a schema:
+
+``` js
+
+const bookSchema = Joi.object({
+    title: Joi.string().required(),
+    author: Joi.string().required(),
+    isbn: Joi.string().length(10),
+    pageCount: Joi.number(),
+    datePublished: Joi.date().iso()
+});
+
+```
+
+``` js
+
+joi.validate(data, schema, callback)
+
+// callback is an optional callback function which takes an error and the validated data.
+
+```
+
+Useful links:
+
+[Joi Documentation](https://github.com/hapijs/joi)
+
+[Hapi Validation documentation](https://hapijs.com/tutorials/validation)
+
+[The Joi Of Validation](http://vawks.com/blog/2014/03/22/the-joi-of-validation/)
+
+https://github.com/hapijs/joi/blob/master/API.md#joi

week-7/authentication/server.js

@@ -8,8 +8,6 @@ server.connection({
   port: 3000
 })
 
-// const schema = joi.object().keys({
-// });
 
 const routes = [
   {
@@ -22,7 +20,8 @@ const routes = [
       validate: {
         params: {
           email: joi.string().email().required(),
-          password: joi.string().regex(/^[a-zA-Z0-9]{8,20}$/).required()
+          // password: joi.string().regex(/^[a-zA-Z0-9]{8,20}$/).required()
+          password: joi.string().alphanum().required()
         }
       }
     }