In this video, we will learn about the Events Core Module in Node.js and then we will also understand the Event Emitter class of Node.js and the methods that we can use on the event emitter instances that we create to listen for an event ( on method ) and to fire an event, we have the emit method that is used to emit an event name to which you can optionally pass a payload as well.
In this video, we will understand how Node.js works and then we will understand the difference between the blocking and non-blocking architecture. Node.js as we know is asynchronous and non-blocking and we will understand why this architecture that Node.js uses is better than a conventional blocking architecture.
So we again have our client and server. The client in order to authenticate needs to first send the authentication data (credentials), so basically the email and the password. This password is then compared with the password that is kept in the database before granting the access to the user. Now if you are working with an Express based server, then you must have used a package called bcryptjs that helps with all of this stuff. In traditional applications, we used to check data on the server and if the data was valid and if it was valid, only then a session used to get established.
Why no sessions any more ?
Well, there is a reason for this. We do not use session any more because REST APIs are stateless. The client and the server do not share the same connection history which means that both are totally decoupled from each other. Here we don’t care about the clients. Every request is treated as standalone which means that every request should have all the data it needs to authenticate itself. With session, the server has to store the information about the client that it is authenticated and this is not how REST APIs work. Therefore this approach is not what we use nowadays.
Now here in this approach we will still check the validity of the email and password combination on the server. But contrary to what we do in case of sessions, here we return a token to the client and that token is something that gets generated on the server. This token would hold some information that can be validated by the server and this token will then be stored in the client so basically in the local storage of the browser. The client can then attach this token to every subsequent request it sents to the server. Stored token is sent to authorize subsequent request and targets the resource on the server which requires authentication. That token can only be validated by the server who created that token.
Now what if you try to change or fake the token ?
If you try to change or fake the token on the client side, then that will be detected because the server uses a special algorithm to generate the token and you simply cannot fake it since the algorithm that uses to generate the private key is not known to you.
What’s that token ?
JSON data + Signature => => => JSON web token (JWT)
This JWT (json web token) is what gets returned to the client and the signature can only be verified by the server. So you cannot edit or tamper the token at the client because the server will detect and will invalidate the token. This is how authentication is done in REST APIs. So in essence, we have a token which can be checked by the server but need not be stored by the server.
So generating the token is one thing, the server sends the token. Next we need to make sure that we can send the token back to the server/backend REST API and then we check for the existence and the validity of token before we allow the request to continue.
If no token is attached to the incoming request, we should simply block access to those routes which do require some form of proven authentication. Remember, it is for the private routes that you do need a token attached to the request so that the user can access them.
Now to basically append the token with request you could attach the token with query params of the url or you could send them inside the body of NON-GET requests. But the best solution would be to send the token along with the headers. The benefit of this is that this would keep your URL clean. Also headers makes a lot of sense for the meta information which our token is in the end.
Now with Express.js, we use the jsonwebtoken package for decoding and verifying our token on the backend.
We use jsonwebtoken.verify to both encode and verify the token on the backend. We can also use jsonwebtoken.decode at the server side as well but then it won’t verify the token there.
The REST API server doesn’t care about the client. Requests are handled in isolation which means that every request is treated as if it arrived for the first time. So here we don’t use sessions. The REST APIs does not store any sessions. They don’t store any client data.
Due to no involvement of sessions in REST APIs, authentication works a bit differently here. Each request needs to be able to send some data that proves the authenticity of that request. JSON Web Tokens are a common way of storing authentication information on the client and proving the authentication status.
JWTs are signed by the server and can only be validated by the server.
So this is it for this article. Thanks for reading.
If you enjoy my articles, consider following me on Twitter for more interesting stuff :
⚡Twitter : https://twitter.com/The_Nerdy_Dev
Don’t forget to leave a like if you loved the article. Also share it with your friends and colleagues.
In this article, let us learn about one of the most important concepts that you as a developer must have a solid knowledge of and that is Advanced Authentication and Authorization.
Advanced Authentication and Authorization
Let us consider the case of resetting of the user password.
You have to implement authentication in a way that prevents users from resetting random user accounts. Reset tokens have to be random, unguessable atleast in a reasonable amount of time and unique. Therefore reset token is a great mechanism to identify the user for which we need to reset the password.
Whenever a user wants to reset his password, he can click on the reset password link and provide the email to which the reset link will be sent from there they can reset the password. For that we have to create a unique token which also has some expiration date which we will store in our database so that the link which the user clicks includes that token and we can verify that the user did get that link from us. This is an additional security mechanism for changing of password thereby ensuring that the user password can only be changed only the identity of the user has been verified and it is also ensured that the user who is trying to change the password is in fact the owner of the account and is authorized to do so.
Node.js has a core module which helps us in creating secure unique random values. That core module is known as the crypto module.
Here is the link for same if you want to learn more about Crypto module :
Not every authenticated user is allowed to do everything.
Authorization means that we restrict the permissions of the logged-in user. For example, to restrict that no one else is able to add items to our cart, no one can visit a certain protected route if they don’t have the required privileged levels
So to sum it up, Authorization is an important part of pretty much every application. Locking down access for authenticated users. Not every authenticated user should be able to do everything. Instead you want to lock down access by restricting the permissions of your users.
So this was all I wanted to cover about Advanced Authentication and Authorization.
Thanks for reading. Don’t forget to leave a like if you loved the article. Also share it with your friends and colleagues.
In this article, let us learn about how we can render dynamic content to the client (which is not static). Let us first touch briefly on what a template engine is because rendering dynamic content is closely related to what a template engine will help us in achieving.
Template Engines – a brief overview
A template engine is software designed to combine templates with a data model to produce multiple pages that share the same look throughout the site. These are the views in an MVC project.
So this helps us in putting dynamic content on our HTML pages.
We got a HTML like template (technically not HTML) which is typically a file that contains a lot of HTML like content in it but with some placeholders plugged into it and then we have a server (a Node.js Express server or any other server) serving the Node/Express content and then you have a templating engine. that replaces placeholders with HTML content but that content is generated on the server dynamically on the fly taking that dynamic content into account.
Some of the common template engines :
Dynamic content to be rendered in the above example is name. The value of the name variable will be rendered as an HTML page’s paragraph with value of name getting rendered on the fly.
PUG uses minimal HTML and custom template language.
Handlebars uses normal HTML and custom template language
The side effect of Handlebars template compared to Pug is that we cannot run any logic in the Handlebars template we need to pass a variable that has a value true or false(i.e logic is performed outside and passed into hbs template) and then we can render dynamic content.
So this is it for this article. Thanks for reading. Don’t forget to leave a like if you loved the article. Also share it with your friends and colleagues.