This course deals with all things server-side. We base the entire course around the NodeJS platform. We start with a brief overview of the Web protocols: HTTP and HTTPS. We examine NodeJS and NodeJS modules: Express for building web servers. On the database side, we review basic CRUD operations, NoSQL databases, in particular MongoDB and Mongoose for accessing MongoDB from NodeJS. We examine the REST concepts and building a RESTful API. We touch upon authentication and security. Finally we review backend as a service (BaaS) approaches, including mobile BaaS, both open-source and commercial BaaS services. At the end of this course, you will be able to: - Demonstrate an understanding of server-side concepts, CRUD and REST - Build and configure a backend server using NodeJS framework - Build a RESTful API for the front-end to access backend services
Exercise (Video): Express Sessions Part 2
Loading...
From the course by The Hong Kong University of Science and Technology
Server-side Development with NodeJS, Express and MongoDB
242 ratings
The Hong Kong University of Science and Technology
242 ratings
Course 5 of 5 in the Specialization Full Stack Web and Multiplatform Mobile App Development
From the lesson
Halt! Who goes there?
This module is dedicated to user authentication. We first develop a full-fledged REST API server with Express, Mongo and Mongoose. Thereafter we examine basic authentication and session-based authentication briefly. We then develop token-based authentication with the support of JSON web tokens and the Passport module.
Meet the Instructors
Jogesh K. MuppalaAssociate Professor
Department of Computer Science and Engineering
[MUSIC]
This is the second part of the express sessions exercise.
We have completed the first part earlier, where we added support for
express sessions, and used express sessions as a way of tracking the users
on the server side and recognizing the incoming requests from the users.
In this exercise, we are not concentrating so
much on express sessions themselves but we will look at a way of exchanging
our express rest API server to support a new model for
registering and authenticating users.
So we will introduce a new user model and schema into our application.
We already have the /users route,
which express generator has already mounted a users router.
So we're going to leverage that and then update that to support
registration of new users, authenticating an existing user, and
also logging out a user from our server side.
So we'll look at express sessions as a way of tracking the users,
once the user logs in.
And then when the user logs out, the session will be removed from the system.
So how do we go about doing this extension in this exercise?
Let's go and find out.
Continuing with our express rest API server, let's now go into the models.
And then add a new file named user.js,
this is the file where we will create the user schema in the model.
We'll create a simple user schema which tracks the username and
password and also a flag that is set to indicate whether the user
is an administrator or a normal user.
So this is one way of distinguishing among different user types.
So in this file, let's first require('mongoose'),
because we are creating a mongoose schema.
And then we'll create a Schema named mongoose.Schema and
then we'll say var User, so
this is the User Schema that we're going to create.
So we'll say new user Schema and the user Schema will be defined,
as I just mentioned, with three fields here,
called username which obviously would be of the type,
String, and this is a required field and this is a unique field,
you don't want two users with the same username in
your system, so we create the username.
And then the second field is password field, now, of course,
you can extend this user Schema to allow the user to track their entire profile but
we will do that in one of the later exercises.
For the moment, a user is recognized within the system by simply the username
and password, so the password is of the type String and then is required.
And the third field that I'm going to use is called admin,
so the admin is of the type Boolean, and,
And we'll say default, False,
so by default, when a new user is created,
the admin flag will be set to false.
You can explicitly set it to true from within your code in
order to mark a user as an administrative user.
Perhaps you might provide additional privileges to an administrative user or
perhaps allowing administrative user to perform certain operations that normal
users would not do so.
We will look at that in one of the later exercises, for
the moment, this is the user schema that we have created.
Let's create a module out of this and
an export from this module, a mongoose module,
Of the name User, so this is the mongoose module.
And the schema is the User schema that we have just defined a little bit earlier,
so this is how we define our User Schema.
So now that we have defined our User Schema,
let's go into the router that has already been set up by express generator,
when it generate this express application.
So if you go into the routes folder, you will see this file called users.js.
So this users.js file will be extended
to create the router, so right there,
what I am going to do is to import bodyParser.
And then we'll declare the express
router and then we'll say,
also import the User schema and
model from models/user.
And then for the express.Router,
we'll say router.use(bodyParser).
So now that we have declared the bodyParser in there,
we're going to leave this part as such.
Later on, we will modify this to allow the administrator to
be able to retrieve all the users that are registered in the system.
But for the moment, we're going to leave that route as such,
we will add in a few more routes here.
So we'll say router.post, so
we'll support a post operation on a route called signup.
And as you expect, the signup route will allow a user
to sign up on the system, so this will support,
The signup of the user, so we'll say req, res, next.
And so this would be that router.post signup,
the remaining methods will not be allowed on the signup end part.
So to access this, since this users router is mounted on /users,
so we will specify this endpoint as /users/signup.
And this is the endpoint that will be used to sign up new users within the system.
So first thing that we will do is use the user method
and the expectation is that for a user to sign up,
the username and password will be provided as a json string
inside that body of the incoming host request, so.
From the body, since the body would have been already parsed by the body parser.
So from the body, we'll first check to make
sure that that username doesn't exist within the system.
If the username exists, then you are trying to sign up a duplicate user and
that should not be allowed in the system.
So we'll say, User.findOne.
And then we'll try to find if there is one user with the username
that has been selected by the client that is trying to sign up a new user.
If the user already exists,
then obviously you won't allow that new user to sign up with the same username.
So we'll say .then((user)).
So this will return the the user here.
And inside this user field, then we will check for
the fact whether the user already exists, and
then let me catch the error here.
So we'll say .catch((err) and then next(err)).
So we will just pass the error on to the error handler, there.
So if the user, so if the search for the user returns the user field,
if(user != null ).
So if the user that is returned by this search is not null,
then that means that the user with that given username already exists.
So you should not allow a duplicate signup.
So we'll say, var err = new Error('User '
+ req.body.username + 'already exists!'.
So basically, you're preventing
a duplicate user from signing up.
And then, we'll say err.status = 403.
Which is the forbidden and then exit,
calling the error handler, next(err).
else, which means that the user doesn't exist, so
you should allow the user to be signed off.
So in the else part, we will say return.User.create.
We'll create a new user with the username set to req.body.username.
And then, let me put this in the next line so that it's more clear to you.
And we'll say, password: req.body.password.
Now, we already know that the admin flag by default will be set to false.
So we're going to leave it as such.
And this will let our new user be signed up.
And when the new user is signed up, this will return a promise and
inside of that, we will handle this promise here.
So, this will determine promise from this then, and
then we'll handle it in the next then here.
We'll say then
res.statusCode = 200
res.setHeader.
And we'll say, ('Content-Type',
'application/json').
And we'll say res.json,
({status: 'Registration
Successful'}).
And if you want, we can lower the user into this
reply message here, as a property in the JSON.
We'll say, 'Registration Successful!'.
And then, if there is an error, In this,
Operation will say, next(err).
So that'll handle the error.
If that promise doesn't resolve successfully,
then that'll be handled by that.
So that's it.
So here we have a way for the user to sign up.
So for the user to sign up, the user will do a post on /users,
/signup, and in the body of the message,
the client will include a json string
with username and password properties in that json string.
That's how you sign up a new user.
Now let's see how we will log in the user.
Now we will still use the express sessions
that we have done earlier to track the user.
So, to login a user we'll say,
router.post on the endpoint ('/login').
So on the /login endpoint, We will do a router post,
Well obviously, it's the same function.
You can use the arrow function here for that router post.
I'm going to do the same thing here.
I've got informed of arrow functions.
So we'll do an arrow function here.
And so, for the login, how does the login proceed?
So for the login, what we will do is that we will
go to the app.js file, and then inside this auth,
we are doing the sign up for the user there.
So what I'm going to do is I'm going to copy this whole thing,
because I would be doing all this anyway.
So let me copy all the way from this point onwards, up to the req.session.users.
So the if part of req.session.users, I'm going to copy.
And then, coming to the users.js file, and for the login,
it is exactly how I am going to do the authentication.
So we'll say, if not (!req.session.user), so
that means that the user has not yet authenticated himself,
then you expect the basic authentication as a mechanism for the user to Use for
authenticating service will say var authHeader,
if not authHeader, then they will raise the error, otherwise,
they will retrieve the username and password from the header.
Now, here we were doing if username is equal to admin and
password is equal to password, but
now what we're going to do is we're going to search in
the database to see if that particular user exists.
So instead of doing this here,
instead of doing this if username and
password, it'll say User.findOne and
we'll say username is username.
So this property is equal to this username that we have just retrieved and
then we'll say then((user)).
So, inside this,
Then, so I'm going to move this code inside this then.
Because now, what I'm going to check for is now that I have retrieved the user,
I need to check to make sure that this user is exactly what I am looking for.
So you will say if user.username is equal to,
username, although in principle,
I don't need to do this because I have actually searched for that username.
And then that user, what is returned,
must have the username set equal to the username.
But in any case, just for completeness so
that you understand exactly what I'm doing, I will include that test also.
And then the next part we'll do is we'll say user.password.
And so this password, and we'll return, and so we'l check to see if that
matches the password that has been sent in within that basic authentication here.
So let's say user.password and then for
direct session user, instead of setting the admin,
I'm going to set that as authenticated.
So that means that the user has been authenticated properly, okay?
So at this point, that log in should simply allow the user to log in.
We won't allow it to proceed further beyond this point.
It will just allow the user to log in first.
So here we are saying we'll
return a statusCode of 200.
And we'll say res.setHeader and
Content-Type.
We'll just send a plain text message and
then we'll say res.end('You are authenticated!').
So in this case, the username and
password matches with an existing user that is already registered in the system,
then the user is a valid user, so you should authenticate the user.
So we are just saying res.end('You are authenticated!'),
but note also that we are setting the req.session.user to authenticated, so
that means that the user is recognized as a valid user.
Now, there are two other possible conditions that can occur.
We'll say if (user.password
!== password).
So it is possible that the user name is correct and the user does exist.
But then, they might have typed the password wrong.
So in this case, what I am going to do is to generate
an error and the error would be saying your,
Password is incorrect.
And they will not try to authenticate, so we'll say,
your password is incorrect and error status is 401.
Or maybe we'll set this to 403 because you are not allowing the user to login and
then we'll return error.
Okay, so this is the second part, and
then the third check that I will do if the user is null,
you need to inform the user, saying User,
username, Does not exist.
Okay, so we will send the error there, saying,
'User ' + username does not exist with an error status as 403.
Okay, and then because this is the then inside there,
so we'll also include a catch, with the error.
Has been returned.
So this is the if part, so if req.session.user does not exist,
then we will ask the user to go through the full authentication.
Else, so the else means the direct session user is already set up correctly.
So, we'll say res,
status code, 200, And
they'll say res.setHeader('Content-Type',
'text/plain').
Since the user is already set up, we'll simply return
saying you are already, authenticated.
That is it, so in the login function, so which means that if the user tries to log
in after the user is already logged in, so this will catch that condition here.
So this is the login function that we have implemented here.
So we check for the user and then make sure that if the user has not already
logged in and this is the first time that the user is logging in, then the user
should have submitted the authHeader and then we'll authenticate the user.
If not, then we'll not allow the user to log in.
So all the possibilities that could happen is listed here.
Okay, so now that last
method that we will implement is for logging out the user,
so we'll do a router.get('/logout').
You must be wondering, why do we do a get on the logout rather than a post
which we did on log in?
On login, you need to submit the username and password.
For logout, you're simply logging out yourself from the system.
So you don't need to supply any further information because the server already is
tracking you based upon your,
Session ID, and inside that session cookie here.
So that's why we are not explicitly
needing to send any further information in the body of the message..
So we'll say, if req.session, which means that the session must exist.
Otherwise, you're trying to logout a user that has not logged in.
So it doesn't make sense.
Now the session itself, Provides this method called destroy.
And when you call the destroy method, the session is destroyed.
And the information is removed from the server side pertaining to the session.
Which means that if the client tries to again send the session information which
is stored in the form of a signed cookie on the client side, that will be invalid.
So we need a method of deleting the cookie that is stored on the client side.
Now this operation will remove the session information from the server side.
So that the session is no longer valid.
So at this point, we'll say req.session.destroy.
And then we'll say, res.clearCookie.
So the clearCookie is a way of asking the client to remove the cookie.
And the cookie name is the session-id.
So in the previous exercise,
we saw that the cookie was told with the name of session-id on the client side.
So we are asking the client to delete this cookie
from the client side in the reply message.
And then we'll say, res.redirect, and we'll redirect it to the homepage here.
So this is a way of redirecting the user to another standard page.
So, for example, the homepage of your application.
So this is the way you would handle the logout of the system.
If req.session doesn't exist, then that means that you are not logged in.
So we'll have to generate an error.
So we'll say, var err new Error you are not logged in.
And we'll set that error status to 403.
This is a forbidden operation.
And then generate the error to the error handler.
That's it, so now you see that we have extended the user's
router to support three new endpoints.
The signup endpoint, which allows a user to sign up.
The login endpoint, which allows a signed up user to log in.
And then the logout endpoint, which allows a logged in user to log out of the system.
And in the process of logging out, you're destroying the session on the server side.
You're also clearing the cookie on the client side so that the client cannot
use an expired session to try to contact that server.
One line of correction in users.js.
This should be var User require ../models/user.
Recall that the users.js file is in the routes folder.
And then the user.js file is in the models folder,
which is up one level and then into the models folder.
So this should be ../models/user.
So make the minor correction.
That's it, we have modified the users.js file.
Now the last thing that we need to do is go and fix up the app.js file.
In the app.js file, if you browse into the app.js file,
you would see that we have this /index here and
/users here after the authentication.
Now this will not work for us.
Because if you need to sign up, then the user would sign up and
log in before the authorization is confirmed.
Anyway, the signup and login is for the process of signing up.
So I'm going to move these two up
before the authentication step here.
So we're going to move this up into this location.
So thereby,
an incoming user can access the index file at the slash.
And also access the users endpoint without being authenticated.
But any other endpoint, the user has to be authenticated.
So that is the way we set this up.
Inside the function authentication, we'll say, if not req.session.user,
then notice that this place, we
would not be allowing the user to come in here without the user having logged in.
So if not req.session.user, then we would simply say, you are not authenticated.
This authentication has to be done by using the login method here.
So I'm going to remove this whole part here.
So we'll say, if not req.session.user, we'll say, you are not authenticated.
And so we will have to send a 403 here.
Which means that you should never come down into this point at all
without the user logging in.
So we'll say, you are not authenticated.
Recall that you need to authenticate yourself by
doing a post on the /users/login endpoint.
So we'll say, you are not authenticated.
Otherwise, if req.session.user is equal to.
Recall that in the login function in the users.js,
we have set the req.session.user to the string authenticated.
So that is what we're going to be checking for.
We'll say, if req.session.user is authenticated, we'll say, next.
Else, you are not authenticated again.
And then we will send back a forbidden message error.
That is it.
So with this update, my app.js file is also ready.
Now having done these updates, let's go and check how our application works now.
Going to the terminal, if your server is running, stop it,
and then restart your server.
My server is not running at the moment, so I'll say, npm start.
And my server should be up and running.
Let's now see how we will access the server.
Going to Postman, let me do a GET on localhost:3000/dishes.
And then you would immediately see that it complains,
saying you're not authenticated.
Obviously, I am not authenticated here.
Let me try to access just the localhost:3,000, and
you will see that, that route is available for us.
Now of course, we want to first register a user and then log in as the user.
And then thereafter, get access to that rest of that REST API in part.
So first, let me register a user.
To register the user, I need to do a,
POST to the localhost:3000/users/signup.
And for this POST message,
in the body of the message,
I need to include in the body of the message,
A JSON string with a username, so
let me log in myself and then I'll
just use the password as password.
This is a valid registration.
So when I sign up as a user with this information
in the form of a JSON string included in the body of that message.
Let me see that the header now contains content type application JSON,
because I've set up the JSON in the body of the message.
And then, send the POST to the sign up.
And then, when I send the POST to the signup,
you immediately see what is returned by the server here.
So you see that the server has returned saying, registration successful.
And the user itself, it gives me the details of the user here.
And so, this is a [INAUDIBLE] that exists in my MongoDB.
And note that the model type is the users model type that we had setup.
So we have the username and password, and
admin flag as you can see is set to false by default.
Once we register the user, this user is now a valid user.
So let me try to again POST the same user and see what happens.
So when I POST the same user,
obviously from the server side, it replies saying, this user already exists.
So you can see that we have set up our sign up procedure
to not allow the user to duplicate register with the same user ID.
So that's the second part.
Now, let's do a login of the user.
To do a log in of the user, let me remove the content type and
then I'll also remove the body, because for the log in that is not required.
So I don't fill in anything in the header, and then try to log in.
When I tried to log in, it replies back saying,
you are not authenticated, you are unauthorized.
So now, I need to log myself in.
So this is where I can use the basic authentication.
So in the basic authentication, I'm just going to
type in my username and password that I just registered in the previous step.
And then, update my request, and then do a POST on the login.
So when I do a POST on the login,
you'll see that there are several replies saying you are authenticated.
So at this point, I can perform the GET, PUT, POST and
DELETE requests on all the other endpoints.
So at this point, if I do a GET on, The dishes endpoint.
You would see that this returns the empty field,
because my database is currently empty at the moment.
Let me clear out the authorization, and also from the header remove
the authorization and then do the GET and it still works just fine.
So you can see that I am now able to access the end points,
because I have logged myself in.
So now let me do a logout of the user, so
we'll say localhost:3000/users/logout.
Note also that in the cookies,
a cookie has been set up with the session-id, right there.
So that cookie exists on my client's site.
So now let me log myself out by saying GET localhost:3000/users/logout.
So when I do a logout of the user, you would immediately see that I am redirected
to the localhost:3000 endpoint.
And also notice that the cookie is gone.
So when I look at cookies, you see that the localhost, the cookie is gone.
Because from my server side, when I do the logout,
it sends back a REST clear cookie to the client side and so the cookie is gone.
Now if I try to do a GET on the localhost:3000/dishes endpoint,
this will not work because I'm not authenticated.
So this demonstrates to you how you can extend your Express Server to allow
users to distribute themselves, and then allow the user to log in to the system,
and then also logout from the system.
And on the server side, you are tracking a logged in user using the session and
using the cookie on the client side.
And when the user logs out, the cookie is destroyed on the client side.
With this, we complete this exercise.
This is a good time for
you to do a git commit with the message express-sessions part two.
[MUSIC]
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2018 Coursera Inc. All rights reserved.
