Forem: Sumit Chahar

Serializing and deserializing our user data in passport.js

Sumit Chahar — Wed, 28 Dec 2022 06:37:20 +0000

As mentioned in the previous article passport by default uses serializeUser and deserializeUser methods

SerializeUser method

It is used to store user data in the session storage. It also decides which part of user object will be stored in the session.

When we the auth process runs in passport.js before handling the success redirect it always looks for a serializer method to put the user information in the session.

User.create(profileData, (err, newUser) => {
            if (err) {
              return done(err);
            }
            return done(null, newUser);
          });

This is the reason why it is recommended to pass a second truthy value to the done callback of the strategy after we have created and stored the user in the database. The second argument of the done callback will be the user object and the serializeUser method will have access to it so we can save the user info by passing a key in the done callback of serializeUser method. The key passed is useful in desearilizing the user as mentioned below.

DeserializeUser method

We also have deserializeUser method which can be used to get access to the user data. It has two arguments with the first argument being the key that we passed to the done method in our serializeUser method. We can access the entire user object by using only the key i.e., the first argument of the deserializeUser method.

We will add both of these methods now to our passport.js module file and it will look like this.

We can disable the serializeUser method as well if don't want to use it by default. We just need to pass sessions: false in our index.js file /auth/github/callback route.

router.get(
  "/auth/github/callback",
  passport.authenticate("github", { failureRedirect: "/failure", session: false }),
  (req, res) => {
    res.redirect("/success");
  }
);

That's it we have completed our Github OAuth application.

Thanks for reading the article.

Storing the user data in our database

Sumit Chahar — Wed, 28 Dec 2022 06:36:42 +0000

Now that we have handled our routes and also written the strategy for OAuth in the previous article. We will now save the user information to our database.

Note: We are using mongoDB and mongoose for our application.

We will create a models folder in our project folder and create a User.js file in which will be our User model and we will write the user schema in this file.

The User.js file will look like this -

Now we will connect our local database with our application we will need to import mongoose connect it using mongoose.connect middleware

mongoose.connect("mongodb://localhost/sampleLogin", err => {
  console.log(err ? err : "Database connected successfully");
});

We also need to add a store to our session using instance of MongoStore in which we will pass the url of our local database.

app.use(
  session({
    secret: process.env.SECRET,
    saveUninitialized: false,
    resave: false,
    store: new MongoStore({ mongoUrl: "mongodb://localhost/sampleLogin" })
  })
);

The app.js file will appear like this now -

We've also added passport.session() middleware in app.js which can give us information about the current logged in user in the session.

At last we should also import our User model in the passport.js file. To create new user.

Now by default passport uses serializeUser method to persist user data in the session. We'll use it in the next article to persist user information.

Go to next article 👉

Creating module for our Github OAuth strategy

Sumit Chahar — Wed, 28 Dec 2022 06:35:50 +0000

In the previous article we set up our routes in the index router file. Now we need to create the strategy to use for our Github OAuth application from passport.js.

What is a auth Strategy ?

Strategies are a defined authentication mechanism which is responsible for handling auth requests. A strategy provides information on what basis of data we provide like client_id, client_secret to verify the application with these credentials.

In our Github strategy we need to pass our client_id, client_secret which are required to verify the application and if the application is registered with Github OAuth or not and only then the OAuth flow proceeds. We also pass a third param i.e., callback_url to which we are redirected after the auth process has ended.

The Github strategy will also return us a callback function with accessToken, refreshToken, profile and data. We can perform any operation we want with the data we get from this callback.

We can use the accessToken and refreshToken to authenticate the user once we have them stored in our local database in case we don't want our user to login by going to the Github consent screen every time they want to login.

We will create a modules folder in our project folder and create a file name for example passport.js in the folder. The file will have the following structure.

before we start writing our module file we will need to add it to app.js and preferably before we are initialising our application. As we want to make sure that the first time when our application is initialised our strategy in the module is already stored in the memory.

After importing it in app.js we can proceed further.

In the above file,

We are redirected to the callback url after the auth process is complete the /auth/github/callback is already present in our index.js file.
Next, we need to use the callback function that contains the user data and tokens in the Github strategy and create a user and store it in our local database.

Go to next article 👉

Handling Routes for our passport application

Sumit Chahar — Wed, 28 Dec 2022 06:35:11 +0000

In the previous article we registered our application on Github and we've got our config variable. We need to setup our routes for passport authentication with Github.

In our index.js file in the routes folder we will set up the routes to use OAuth.

Now we need to configure our routes for handling the OAuth process

Our index.js file will look like this,

'/' the index route to render our index page where we'll have our login button.
'/success' to redirect user if auth is successful.
'/failure' to redirect user to failure page if auth is unsuccessful or an error occurs.
'/auth/github' we'll make a get request to auth/github route and pass the middleware passport.authenticate passing "github" as param to authenticate with Github strategy.
'/auth/github/callback' this route will work after the OAuth process is complete and we get either an error which means the failureRedirect option will trigger and we'll be redirect to the /failure route. If auth is successful then we'll be redirected to the success page and the users profile data will be available to us.
'/logout' for logging out of current session.

The auth/github route makes use of Github Strategy which is a defined protocol that has to be followed and there are different strategies for different OAuth provider for example, google OAuth strategy will be different in comparision to the Github OAuth Strategy.

We'll set up our OAuth strategy in the next article.

Go to next article 👉

Register OAuth Application on Github

Sumit Chahar — Wed, 28 Dec 2022 06:34:30 +0000

The first step in creating our Github OAuth application is registering our app on Github.

You will need to follow the below steps -

go to your Github account and navigate to /setting/developers.
Choose OAuth apps and create a New OAuth app.

In this step we have to give our application a name and a homepage URL I am using it on localhost so I've given a localhost URL.
We also need to provide an authorisation callback url here which is the url where the user is redirected to after Github authorise our application.

After Registering the application we'll be redirected to our application settings and provided with the clientID and we need to manually generate the client secret. The clientID and client secret are to be stored in the .env file as these should not be exposed anywhere being sensitive information.

Go to next Article 👉

Creating an OAuth application with Express & Passport in 5 simple steps

Sumit Chahar — Wed, 28 Dec 2022 06:34:24 +0000

In this series of articles we will be creating a basic Github OAuth application using Express.js. We'll also use Passport.js as our authentication middleware.

We will be using mongoDB, mongoose for the database and also use session storage for this application.

To setup our app we need to follow the following steps -

install node, npm, mongoDB, express, express generator if not installed.
create a project folder and in your project folder use the express generator to initialise our application.
while creating the express application make sure we have installed the following dependencies these will be available in package.json -

express
passport
passport-github
express-session
dotenv
connect-mongo
debug
ejs (or any templating engine)
mongoose
http-errors
morgan

We will setup our ejs templates first -

In the views folder we will create our templates since this will be only a backend application.

we will just add a link that points to our OAuth route for now, you can create these to your liking later. You can also create success, failure views, etc.

The folder structure after we complete our app will look like this for reference -

Creating the application

There are 5 steps in which we will be creating our Github OAuth application -

Register Application.
Handle Routes.
Create Strategy for Github OAuth.
Adding copy of user data in our local database.
Serialize & deserialise.

Go to next article 👉

Introduction to OAuth and OAuth Flow

Sumit Chahar — Tue, 27 Dec 2022 08:43:46 +0000

What is OAuth

OAuth is a delegated authorisation protocol that allows users to share information between services without exposing their password.

An example of OAuth can be a website or an application asking their users to register or login via some other applications like google, Github, etc.

Main motive of using OAuth is to provide authorisation and not authenticating the users.

OAuth Flow

In OAuth we deal with three interfaces -

Browser application
Server
OAuth Provider

Below is how OAuth flow works we can take example of logging in with google,

In our application or website in the browser we choose to sign in with google.
The login router passes the instruction to the OAuth middleware which is middleware performing operation like providing the correct strategy based on our OAuth service provider, granting tokens, attaching the user information with the current session, etc.
When permission is granted from the consent screen by the user an access token is generated.
The access token is passed to the authorisation server which provides user information if the access token passed is correct.
The response from the OAuth provider server is passed into our callback function and profile data can be extracted from it.
After we have the profile data we can provide authorise to the user or store data in our local database, etc.

👏 Thanks For Reading the article !

Function Hoisting In JavaScript

Sumit Chahar — Sat, 10 Sep 2022 07:23:15 +0000

In the previous post we talked about variable hoisting. Now we are going to look at function hoisting in JavaScript.

There are two main types of functions in JavaScript -

Function Declarations
Function Expressions

In this post, We'll can understand function hoisting by looking at how function declarations and function expressions behave in the creation and execution phase.

**Hoisting Function Declarations

we'll analyse the below example to understand how function declarations are hoisted -

The below happens in the above example -

In the creation phase the javascript engine encounters the function keyboard and the default behaviour is that when a function declaration is encountered it's hoisted in the memory with its complete function body.
When the execution phase starts and the add function is called the full function body is already available in the execution phase so this program outputs 3.

**Hoisting Function Expressions

The way function expressions are hoisted is similar to how variables get hoisted as a function expressions is simply assigning an anonymous function to a variable so that we can later execute that by referring to the variable name.

We can conclude from above examples that hoisting the function expressions happens the same way as the variable hoisting.

In the first example, we get an error add is not a function as the variable add was hoisted in memory with a value of undefined thus the Js Engine expects add to be undefined and not a function so it throws an error in case we access it before initialisation.
For the second one i've replaced var with let and it gives an error again as let/const declarations are only given memory in the creation phase but not a value so it results in the error cannot access 'add' before initialisation.
The third example does print the expected output as we are accessing the variable add only after its initialised in out program so the variable add gets initialised to the anonymous function and we get the output 3 on calling it.

Variable Hoisting in JavaScript

Sumit Chahar — Sat, 03 Sep 2022 10:22:38 +0000

Introduction

Hoisting is one of the most interesting and important topics in JavaScript to understand how different variables, function, classes declarations and definitions behave in a JavaScript program.
For someone new to JavaScript with no prior experience hoisting can be a confusing as most languages don't handle variable and function declarations the way javascript does and it requires some knowledge of how the JavaScript Engine behaves during code execution to understand Hoisting.
Hoisting along with Thread of Execution, Scope, Closures is also one of the most popular topics in web dev interviews for entry level jobs.

Prerequisites

To understand hoisting one should have some knowledge of thread of execution, Execution Context and what are creation phase & execution phase in JavaScript.

What is hoisting?

Hoisting is storing the variables declared in the code into the memory when the code execution is in the creation phase. Variables, functions, etc. are all stored in the memory to be available to use when the execution phase begins.

Hoisting moves all the variables and functions declarations to the top of their scope to make them available to use before they are even declared

we can understand the above statements by looking at the below examples -

We'll go through all three of these and try to understand what's happening here. The knowledge of creation and execution phase will come in handy here.

1. In the first example the following explains why undefined is logged :

The javascript engine reaches the declaration var helloWorld it hoists it into the memory and there's a default behaviour in which the var declarations are hoisted i.e., they are hoisted by assigning them value of undefined during the creation phase.
The line console.log(helloWorld) being a function call doesn't get hoisted.
When we come in the execution phase the function call to log the value of helloWorld variable prints the value as undefined since it was hoisted as undefined in the creation phase.

2. For the second example the result is undefined too :

In creation phase first line being a function call is not hoisted. We reach the variable declaration var helloWorld = 'Hello World' which is hoisted but now we come to an important point.

Initialisations are not hoisted during the creation phase only declarations are.

As JS Engine hoists var declarations with a value of undefined the variable will be hoisted with a value of undefined and not Hello World!.
The reason why console.log(helloWorld) prints undefined is that when we're in the execution phase and reach line one the initialization has not taken place yet for our helloWorld variable so we're reading it before its initialized meaning it's value is still undefined as we log it.

3. The third example will make things more clear about how hoisting works and what happens during creation and execution phase :

In the creation phase helloWorld gets hoisted with a value of undefined.
Now in the execution phase the first console.log will print undefined as we've already seen in example 2.
The execution reaches line 2 where we've initialized the value of helloWorld to Hello World! so the value for our variable helloWorld changes from undefined to Hello World! here.
The line prints the message Hello World because we've initialized the value of our variable before the last console.log.

From Above examples we've made the below observations :

Variables are available to use before initialising/assignment of a value in the execution phase.
initializations are not hoisted during creation phase so only the default value of undefined got assigned to our variable even though we initialized it in example 3.
In the execution phase a variable will only be assigned a value when it reaches the part of code where its being initialized and not before that.

How Hoisting is different for Var, let & Const ?

The difference between hoisting of a var declarations with those of let and const declarations is that var is hoisted in memory with an actual value i.e., undefined.

let declarations :

These are allocated memory during the creation phase but not initialized with any value, keeping them in memory as empty boxes that contain no value before they've been initialized in the excecution phase.
In the execution phase when a let variable is read before its initialization then the variable will be assigned a value of undefined as we can see from the result of first console.log in example #2 in the below image.

const declarations :

These declarations should always be initialized before they are used as they never get assigned a value of undefined like let declarations are assigned in the execution phase making them always throw an error if not assigned a value while declaring them.

That's it for this post 👏🏻.
Thanks for reading this post. Please post feedback, ask questions if any related to this topic.

HTML Page Structure & Semantics

Sumit Chahar — Fri, 27 Aug 2021 11:37:33 +0000

Hey coders

We come across different website designs every day and almost every one of them has a different structure which is defined by positioning HTML's grouping elements in different ways.

HTML Page Structure

You can see The most basic structure that we come across on the web in this image.

The elements in the given picture are the thematic grouping elements or we can say semantic elements that we use to structure our page. Let's go through these one by one -

header - This element is used for the introductory purpose we usually contain our logo, nav menu, etc. inside this element.
main - The main element is used to hold all the meaningful content of the page that we want our visitors to go through i.e, all the section, article, aside tags come inside it. NOTE: There should only be one main element in an HTML document.
section - Section is used to group associated content such as different articles, information cards, etc.
article - We use an article when there's a piece of content on our page that is independent of other content on our web page. for example, a blog post or a news story, etc. The article tag is contained in the section tag.
aside - aside is the element used to contain the sidebars on our page.
footer - Footer is used for containing content like copyright information, site links, newsletter forms, etc.

One thing to note here is that the footer and header can be kept inside the main element also but one could argue that these should be outside the main as they usually don't hold content that is directly related to the central topic of our document. So we should try to use them only as a descendent of section, article or any other element while using them inside the main element. Whereas, the header and footer of the whole website should be kept outside the main element.

HTML Semantics

Now, you must be thinking we can use a <div> rather than using any of these elements to make any possible style,and it's correct too but this is also where the necessity of using semantics and semantic elements come into play.

What is semantics?

Semantics in terms of HTML simply means describing the meaning of our given content to the browser and ourselves(the developers). The generic elements we discussed above do just that. For example, using a <table> tag to define a table for our page instead of a <div>, <article> or <section> provides better semantics as it clearly defines that there's a table here.

Why not use <div> instead

So we know the meaning of semantics now and how they provide meaning to our content let's come back to the question of why can't we use <div>, <span>, etc. for these purposes. The answer is simple the sole purpose of a <div> is for grouping and styling our content but not to provide semantic meaning to our page. <div> does not provide any meaningful information regarding the type of content to the browser or the developer himself.
So, <div> has its use case and that is the grouping and then styling the content.

Benefits of using Semantic tags

These are some key benefits of semantic tags that you should know in case you are about to avoid using them

Clear indication of the role played by our content
Better readability of code
Offer SEO benefits
Better consistency with the new HTML5 specifications

Semantic tags are for containing the content so that it provides some meaningful information about itself and you should try to avoid using them for styling purposes whereas, <div> is for styling the content that we have inside our semantic elements.

Thanks for reading the article ✌️.

A brief introduction to HTML & CSS

Sumit Chahar — Sun, 22 Aug 2021 07:46:47 +0000

What are HTML & CSS

HTML & CSS are languages made for the web. HTML & CSS are like those best friends that can't stay without each other for one to exist other's existence is important.

At the same time, One thing to note is that you may have HTML without CSS but it will only come to life when you actually style it with some CSS.

Now, let's see what HTML and CSS are and how they work.#HTML

HTML provides the markup for all the raw content that we want to display on our page.
In an HTML document, you can just write anything inside the document and it will display on the page but every HTML page should have a standard document structure that we must follow to make sure the browser renders our code properly and gives meaning to our content.

Given below is the most basic structure of an html document.

There are different HTML elements and tags that define the structure of our page let's go through all of them

<!DOCTYPE html> - This tells the browser what kind of document to expect as in our case here it is an html document.
<html> - This tag represents the root of our document all the html elements are contained inside this.
<head> - It holds information about the metadata, properties of our web page and links to external files that we are using on our page.
<Body> - This element contains all the raw content which we want to display on our web page. Everything we see on a web page is contained inside the body tag.

CSS

CSS is the style sheet language which used for formatting and styling our HTML document. We use it to beautify our page.
For CSS to work we must have an HTML document because we need a web page to make sure that our CSS styles show up for this we need to embed or link our CSS with the HTML document.
There are three ways by which we add CSS to our HTML document -

Inline CSS - Inline CSS is used to apply styles to an element by using the style property writing it inside the element's opening tag. It is meant to be used when we want to apply some unique styles for a single element.
Internal or Embedded CSS - Embedded CSS is written inside the <Head> element which is where we store all the page related information. We simply open a <style> tag inside the head and write all our styles inside it.
External Stylesheet - In this method you simply create a '.css' file and link it with your HTML document providing file path inside the <link> tag of <head> element.

Out of the above three methods inline and embedded/internal CSS are not recommended as they don't separate content from design and are difficult to maintain. Thus it is recommended that you use an external stylesheet for your CSS styles which keeps all your styles at one place making sure you don't need to go through the whole HTML document to debug a small chunk of code.

We may say that -

HTML is what we want to say and CSS is how we want to say it