ES7 Streams, Promises and Thunks

Why I am switching to promises? By @spion

In ES7, promises will become monadic (by getting flatMap and unit). Also, we’re going to get generic syntax sugar for monads. Then, it trully wont matter what style you use – stream, promise or thunk – as long as it also implements the monad functions. That is, except for callback-passing style – it wont be able to join the party because it doesn’t produce values.

I’m just kidding, of course. I don’t know if thats going to happen. Either way, promises are useful and practical and will remain useful and practical in the future.


Implicit Grant Type – OAuth 2 Authorization Flow

The implicit grant type is used to obtain access tokens and is optimized for public clients known to operate a particular redirection URI.

From OAuth 2 Authorization Framework RFC

The implicit grant type is used to obtain access tokens (it does not
support the issuance of refresh tokens) and is optimized for public
clients known to operate a particular redirection URI. These clients
are typically implemented in a browser using a scripting language
such as JavaScript.

Since this is a redirection-based flow, the client must be capable of
interacting with the resource owner’s user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection)
from the authorization server.

Unlike the authorization code grant type, in which the client makes
separate requests for authorization and for an access token, the
client receives the access token as the result of the authorization

The implicit grant type does not include client authentication, and
relies on the presence of the resource owner and the registration of
the redirection URI. Because the access token is encoded into the
redirection URI, it may be exposed to the resource owner and other
applications residing on the same device.

(A) The client initiates the flow by directing the resource owner’s
user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).

(B) The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client’s access request.

(C) Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier. The redirection URI includes
the access token in the URI fragment.

(D) The user-agent follows the redirection instructions by making a
request to the web-hosted client resource (which does not
include the fragment). The user-agent retains the
fragment information locally.

(E) The web-hosted client resource returns a web page (typically an
HTML document with an embedded script) capable of accessing the
full redirection URI including the fragment retained by the
user-agent, and extracting the access token (and other
parameters) contained in the fragment.

(F) The user-agent executes the script provided by the web-hosted
client resource locally, which extracts the access token.

(G) The user-agent passes the access token to the client.

Authorization Request

The client constructs the request URI by adding the following
parameters to the query component of the authorization endpoint URI
using the “application/x-www-form-urlencoded” format:

REQUIRED. Value MUST be set to “token”.

REQUIRED. The client identifier


OPTIONAL. The scope of the access request

RECOMMENDED. An opaque value used by the client to maintain
state between the request and callback. The authorization
server includes this value when redirecting the user-agent back
to the client. The parameter SHOULD be used for preventing
cross-site request forgery.

The client directs the resource owner to the constructed URI using an
HTTP redirection response, or by other means available to it via the

For example, the client directs the user-agent to make the following
HTTP request using TLS (with extra line breaks for display purposes

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1

The authorization server validates the request to ensure that all
required parameters are present and valid. The authorization server
MUST verify that the redirection URI to which it will redirect the
access token matches a redirection URI registered by the client.

If the request is valid, the authorization server authenticates the
resource owner and obtains an authorization decision (by asking the
resource owner or by establishing approval via other means).

When a decision is established, the authorization server directs the
user-agent to the provided client redirection URI using an HTTP
redirection response, or by other means available to it via the

4.2.2. Access Token Response

If the resource owner grants the access request, the authorization
server issues an access token and delivers it to the client by adding
the following parameters to the fragment component of the redirection
URI using the “application/x-www-form-urlencoded” format, per
Appendix B:

REQUIRED. The access token issued by the authorization server.

REQUIRED. The type of the token issued as described in
Section 7.1. Value is case insensitive.

RECOMMENDED. The lifetime in seconds of the access token. For
example, the value “3600” denotes that the access token will
expire in one hour from the time the response was generated.
If omitted, the authorization server SHOULD provide the
expiration time via other means or document the default value.

OPTIONAL, if identical to the scope requested by the client;
otherwise, REQUIRED.

REQUIRED if the “state” parameter was present in the client
authorization request. The exact value received from the

The authorization server MUST NOT issue a refresh token.

For example, the authorization server redirects the user-agent by
sending the following HTTP response (with extra line breaks for
display purposes only):

HTTP/1.1 302 Found

Developers should note that some user-agents do not support the
inclusion of a fragment component in the HTTP “Location” response
header field. Such clients will require using other methods for
redirecting the client than a 3xx redirection response — for
example, returning an HTML page that includes a ‘continue’ button
with an action linked to the redirection URI.

The client MUST ignore unrecognized response parameters. The access
token string size is left undefined by this specification. The
client should avoid making assumptions about value sizes. The
authorization server SHOULD document the size of any value it issues.

Prototype Methods ES6

class Car { // make new cars
 constructor(make, colour) { // add a prototype method
 this.make = make;
 this.colour = colour;

const beemer = new Car("BMW", "red");
const subie = new Car("Subaru", "white");
// console.log("my cars are: ", beemer, subie);

// Now, after the fact, I added on this prototype method:

Car.prototype.summarize = function() {
 return `This car is a ${this.make} in the colour ${this.colour}`; 

console.log(subie.summarize()); // This car is a Subaru in the colour white
console.log(beemer.summarize()); // This car is a BMW in the colour red

Source by @wesbos

JavaScript Template Literals

ECMAScript 6 feature called template strings literals.

Template literals are string literals allowing embedded expressions. You can use multi-line strings and string interpolation features with them. They were called “template strings” in prior editions of the ES2015 / ES6 specification.

`\`` === "`" // --> true
var a = 5;
var b = 10;
console.log(`Fifteen is ${a + b} and\nnot ${2 * a + b}.`);
// "Fifteen is 15 and
// not 20."


Immediately Invoked Function Expression IIFE JavaScript

Immediately-Invoked Function Expression (IIFE) explanation from Ben Alman

Immediately-Invoked Function Expression (IIFE)

Explanation from Ben Alman

// Either of the following two patterns can be used to immediately invoke
// a function expression, utilizing the function's execution context to
// create "privacy."

(function(){ /* code */ }()); // Crockford recommends this one
(function(){ /* code */ })(); // But this one works just as well

// Because the point of the parens or coercing operators is to disambiguate
// between function expressions and function declarations, they can be
// omitted when the parser already expects an expression (but please see the
// "important note" below).

var i = function(){ return 10; }();
true && function(){ /* code */ }();
0, function(){ /* code */ }();

// If you don't care about the return value, or the possibility of making
// your code slightly harder to read, you can save a byte by just prefixing
// the function with a unary operator.

!function(){ /* code */ }();
~function(){ /* code */ }();
-function(){ /* code */ }();
+function(){ /* code */ }();

// Here's another variation, from @kuvos - I'm not sure of the performance
// implications, if any, of using the `new` keyword, but it works.

new function(){ /* code */ }
new function(){ /* code */ }() // Only need parens if passing arguments


OAuth 2 API Authorization Simplified

This post describes OAuth 2 in a simplified format to help developers and service providers implement the protocol.

This post describes OAuth 2 in a simplified format to help developers and service providers implement the protocol.


The Third-Party Application: “Client”

The client is the application that is attempting to get access to the user’s account. It needs to get permission from the user before it can do so.

The API: “Resource Server”

The resource server is the API server used to access the user’s information.

The User: “Resource Owner”

The resource owner is the person who is giving access to some portion of their account.

OAuth 2 Redirect URIs

Service will only redirect users to a registered URI, which helps prevent some attacks. HTTP redirect URIs must be protected with TLS security, so the service will only redirect to URIs beginning with “https“. This prevents tokens from being intercepted during the authorization process.

Client ID and Secret

After registering your app, you will receive a client ID and a client secret. The client ID is considered public information, and is used to build login URLs, or included in JavaScript source code on a page. The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as JavaScript or native apps, then the secret is not used.

OAuth 2 Authorization

The first step of OAuth 2 is to get authorization from the user. For browser or mobile apps, displaying an interface provided by the service to the user.

OAuth 2 “grant types”