All language subtitles for 017 Analyzing Further Authentication Requirements_Downloadly.ir_en

Over the last lectures,

we ensured that we can

log in and log out and create users.

And that we protect certain pages.

And that we control which page can be visited,

if we're locked in or locked out.

That certain pages like the profile page

can't be visited that were redirected automatically.

And all of that works now.

All of that works with help of the Next Auth package,

and the session which it checks for us.

And just to make this really clear,

when I say session here,

I am talking about this json web token.

Which is managed automatically by Next Auth.

Which is stored by Next Auth

in our browser this cookie,

which holds this token is created there.

And Next Auth determines whether

we have an active session,

so if this user is logged in,

by checking that cookie and that token

that's stored in that cookie.

That is what happens when we call getsession here,

or in our main-navigation component

when we use the useSession hook.

And that's what we did up to this point.

Now one crucial feature is missing,

one of the main reasons for adding authentication.

Because having this client site protection here is nice,

protecting certain pages and making sure

we can't reach certain pages,

is all nice and good.

But what really matters,

is what we as a user can do.

Which API routes we can hit.

Here we got this change password example.

But of course for example,

if you're building an online shop,

you might only want to allow logged in users,

to create and delete and manage products.

And in the interface which your website

has for managing those products,

you would be sending requests behind the scenes,

to certain API end points,

certain API routes.

Where those requests then trigger certain operations.

Like the creation of a product

or the deletion of a product.

And of course you want to make sure that,

those requests only trigger those operations,

if they come from authenticated users.

So that if you have API routes in your project,

API routes that do certain operations

that are only allowed for authenticated users,

that in those API routes you also verify,

whether that request is coming

from an authenticated user or not.

Because even if you have full control

over this user interface,

requests to APIs can also be sent with other tools.

From the command line, with tools like Postman

which allows you to create http requests.

So there are ways of sending requests to APIs,

that don't require your website.

And therefore protecting the pages on those websites,

is one thing but we also need protection

in those API routes.

Where we validate incoming requests,

and double check that this request

is coming from an authenticated source.

And I'm emphasizing this here,

because this is another key part of authentication.

It's not just about the client site,

it is also about the server site ,

about those API routes.

And that's therefore what we're going to

take a closer look at now.