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
Basic Authentication
Loading...
来自 The Hong Kong University of Science and Technology 的课程
Server-side Development with NodeJS, Express and MongoDB
500 个评分
The Hong Kong University of Science and Technology
500 个评分
课程 4（共 4 门，Specialization Full-Stack Web Development with React）
从本节课中
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.
与讲师见面
Jogesh K. MuppalaAssociate Professor
Department of Computer Science and Engineering
[MUSIC]
The Express REST API server that we implemented in the previous
module allows any user to perform any of the GET or POST or DELETE operations.
There is no control on who can perform this operation.
So which means that,
if you run a server like that, then anybody can come into your server and
start manipulating the information that is present within your database.
This is obviously a dangerous situation.
The way that server should be implemented is that,
you need to have some kind of restriction on
which kinds of users will be allowed to perform which kinds of operations.
So maybe, you would allow and
an authorized user only to perform GET operations.
So for example, if you want a guest to be able to see information
about the dishes in your restaurant or the menu of your restaurant and
so on, that is perfectly acceptable.
But, you may allow only an administrator to go in and
modify the information about the dish or to delete a dish from the menu.
And also update an existing dish in the menu, or a promotion,
or the information about the leaders in your server-side.
Now, you could also have another group of users which will be registered users
who may be allowed to save some of their dishes as their favorite dishes,
and only they would be able to manipulate the list of their favorite dishes.
So that is another level of authorization or
authentication that you need to perform.
So, you have different grades of users, and
also, depending on what kind of operations they would be allowed to perform.
So all this means is that you need some kind of security to be built
into your server-side.
We'll look at how we can authenticate users, and
then decide what kind of user this client is.
And then depending on the type of the user,
you can allow the user to perform certain kinds of operations.
We will start with the basic understanding of this, what we call as
Basic Authentication in a server-side for
a client, and then, build upon that throughout the rest of this module.
And then at the end of this module, we will end up with a mechanism,
thereby, allowing users to register themselves.
And, registered users can perform certain operations
that an unregistered user cannot, and so on.
So we'll impose various kinds of access controls for
various operations on the server-side based upon the kind of user.
So that sets you the perspective, or
rather the idea of what you will encounter in this module.
Let's start with basic authentication,
the very basic mechanism that will enable us to authenticate users.
Basic authentication in HTTP is a very simple mechanism,
which will ask the user for a user name and
password to be submitted with a request.
And there is a specific structure
on how this information will be sent from the client to the server-side.
So, this is a matter, the basic access authentication, which HTTP supports,
is a matter that will enable a server to challenge a client, and ask for
the username and password to be submitted by the client.
So the server can challenge the client to authenticate itself by typing in this
information.
The client needs to send the username and
password in response to the challenge from the server-side.
So, every request message originating from a client
should include the encoded form of the username and
password in the request header that goes from the client to the server-side.
So when the server receives the request,
the server will extract this information from the client's request header.
And then, use that for authenticating the client before
allowing access to the various operations on the server-side.
So, how does this authentication work?
If a client sends a request to the server, and
this client request does not include the authorization formation, then the server
will challenge the client, they're asking for the client to submit this information.
The server challenges the client by including
a header into the reply message coming in.
The header with the type as WWW-Authenticate, and
then the second part where it specifies the type is where it will
specify what kind of authentication the client needs to submit.
And we will start with the understanding of basic authentication here.
And also notice that the reply message will contain a 401 error code,
which is unauthorized, which stands for unauthorized.
So when the reply comes back from the server-side, then the client,
in response to this reply coming in, the client will have to send their request,
including a specific header field in the request message of the type authorization.
And this authorization header field will contain some information in there.
For a basic authentication, this information would be in the form of,
as the first word here, will be Basic.
And then followed by a space here, and followed by a Base64 encoded string here.
This Base64 encoded string encodes the username and
password in a particular format, and then includes that in the header.
Now you're saying, if you send out a request message like this,
including this, in the header, then anybody in the middle.
So if you know anything about security and
how man in the middle attacks can be launched, then obviously,
this can be retrieved by an intruder in between,
and then can be used to fake the real client.
Again, we are not getting into that question at the moment.
When I talk about HTTPS in the next module,
I will come back to address that issue in a bit more detail.
But for the moment, the information in the header will be sent over
without being encrypted in the header at this moment.
Now, one other reason why I'm doing this is that, so that we can actually look at
the header directly and then see this information in the header itself.
So, when the client sends this request, then the server will extract
the information from this authorization header in the request header.
And then use this information in order to verify whether this is
an authorized a client request or not.
Now of course your next question would be,
what exactly does this authorization header contain?
The authorization header itself is constructed as follows.
If you have a username and a password, these are the two
pieces of information that you will use to authenticate a client.
So the username and password will be concatenated into a single string
by saying username and a colon, and the password itself.
So the username string, colon and
password will be concatenated together into an entire string here.
This resulting string that we get here is that, encoded using Base64 encode.
If you know about how encoding is done basics for encoding,
convert that into an ASCII header like as shown in this example here,
so this is nothing but a string of ASCII headers.
Now if you don't know much about basic stiff encoding, don't worry about it,
it doesn't impact your understanding of what is going on here anyway.
So this Basic64 encoded strings, so
this particular information is encoded into a string like this, and
then enclosed in the request header going from the client to the server.
The request header itself is of the type authorization,
and then followed by the actual value here, which says,
Basic, and a space here, and the Base64 encoded string here.
So, when this is received by our sever, the server will extract this information,
and then from here, it'll extract the username and password, and
then verify whether that matches an authorized user or not on the server-side.
To help you better understand how we actually organize the express application
and how the authentication itself is carried out, as we have learned earlier,
express applications themselves are organized in a set of middleware.
And the way the express application works is that the middleware
are applied to the request and the response message
in the order in which it is declared in my express application.
So if you have a express.use and
then you have the first one saying a static server, then after that,
you have another middleware, then after that, you have another middleware.
The sequence in which they are declared in the express servers app.js file,
for example, is the exact sequence in which the middleware will be applied.
So an incoming request from the server-side as you recall in your express
application, the incoming request is treated as a request object.
The response object is what the express server constructs, and
then the next is allows you to go on to the next middleware
that you're going to be applying, and so on.
So, an incoming request like this, when it comes in, the first middleware is applied.
And then once that middleware has transformed both the request and
the response, it moves on to the next middleware, which is then applied to it.
So for example, we saw that we applied Morgan first,
then we applied body parser to the middleware.
So they must have already transformed the request and the response objects.
And then after that, we can include an authentication middleware in place there.
The authentication middleware is going to authenticate the request.
Now, so if you are using basic authentication, do your request
must contain in the header the authorization header in place in there.
So the authorization header will be extracted by the authentication middleware
and then checked to see if the user is authorized.
And if the authentication middleware detects that you are an authorized user,
then you'll be allowed to proceed forward to the next set of
middleware that follows the authentication step.
And your records will be processed by the subsequent middleware.
But other hand,
if your authentication middleware decides that you are not an authorized user,
then the authentication middleware will take you along a different path off.
And then generate an error, and then send back
an appropriate error reply to that client-side and
will be redirected to the error handler.
So this redirection to the error handler will be done by calling Next
with the error as the parameter to that Next here.
So the Next is exactly this Next that we see in the request resource Next here.
And so, that will take you all the way down to the error handler,
which will handle error and then send back the error message back to the client-side,
indicating the failure of the authentication.
So this is how your typical basic authorization, or
basic authentication works in your server-side application.
Having understood this, let's move on to the exercise where we
will implement the basic authentication in our application and
see how it authenticates users.
[MUSIC]
