Welcome back.

Are you feeling refreshed?

Okay so let's get started.

One second first though.

I wanna show you something that I did I made a mistake while we were going through

this and I just automatically created this constructor and

I assume that it was going to be username first over here.

And so when I built all those constructors there were three strings in a row.

And I put the username first and then I put the first name of the last name, but

the order was different so I just want to point that out.

Be careful when you generate constructors like that and kind of assume that that's

how things work and then I was never looking and I was just filling it out.

So, what we do have is this user entity and a matching repository and we added

a search that lets us find an entity using the method find by a user name.

So Now what we need to do is have our code play well with Spring Security.

So, what we need to do is to create what is known as a user details service.

Spring Security expects us to provide this customized for our specific environment.

So, let's build one.

So in the user package let's go ahead and

we're going to make a new Java class and we gonna to call it DetailsService and

we gonna have it implement the user details service.

And there's a lot of the using of the word user, right?

So let's talk about here in a second so we gonna say extends userDetailsService and

I meant actually implements here cuz that's a interface.

Now this user here is what Spring Security is calling the user it's not our

user entity.

This is a common confusion and one that you find on Stack Overflow all the time so

pay close attention to the differences here and I'll point them out.

So our class definition is saying very loudly that we have not

implemented the methods.

So let's go ahead and

we'll do that so the one that we have is this load user by username.

Again not our user, this is somebody that implements user details, and

if we can't find it, what we need to do is throw a user name not found exception.

So, we need to get ahold of our User.

So let's get ahold of our repository, right.

So we are gonna go ahead and autowire that up.

And we'll say UserRepository users, and

we also wanna export this out so that somebody else can find it so

let's go ahead mark this as Component so we don't forget.

So that when the components scan comes,

we can find this is what we can find a user detail service.

All right, so let's do it.

Let's go and use our users.

So we'll say user equals users, our repository and there's our method,

findByUsername, and we'll take the user name that was passed in.

Okay, and if that's not found, so if user name is null,

what we'll do is we'll throw a new username not found exception.

And as you'll see it takes a message, or msg as it says there,

don't be confused with monosodium glutamate.

So username + was not found.

And remember what we're expecting to return is that something that

implements the user details interface.

So, we could make our entity actually implement the user details interface.

But first, let me walk you through the other side of the problem, just so

you can see this.

So here's the naming issue that I was warning about.

So let's just say new and will say user and notice that's not our user.

That's the org.spring.framework.security.core.somet-

hing right.

So if we do that it's going to auto complete everything there.

That's exactly what we want.

Now let's take a look here so the first it takes a username it takes a password and

then it takes a collection of granted authorities.

Okay so let's do that we can definitely get easily get this user.getUsername

right.

And we have the password user.getPassword.

Finally what we want to do here is use a handy

little utility called AuthorityUtils.

And it has a static method that it exposes called create authority list and

that takes an array of roles and we have those under get roles.

Okay.

Our service is looking great and

it can be found because we've marked it with a component.

So what we want to do now is overwrite the default Spring Security and

use this service.

So let's do that.

So if we go to our project, defining the security is pretty core right so

let's drop it in here let's drop it in core.

So we're going to say going to call this WebSecurityConfiguration.

Naming doesn't matter really but except for discoverability by people but

we're going to extend The WebSecurityConfigurerAdapter.

So let's start configuring first thing we want to do is we want to make sure that

Spring knows that this is a configuration file, right?

So we're going to market with configuration.

And the next thing that we're going to do

is we're going to let Spring Security know.

So we're gonna say EnableWebSecurity.

So that lets us bring security now.

And to complete the annotation trifecta.

Let's say EnableGlobalMethodSecurity and

we want prePostEnabled to be set to true which is gonna allow us to

secure our methods and we'll get to that here in a second.

Okay. So

we are going to inject that service that we just built, Autowired.

And the service is called a DetailsService and

it's called userDetailsService.

Now we want to overwrite a couple of configuration methods.

So the first one that we're going to do is this one here, this

configure(auth:AuthenticationManagerBuild- er).

Now notice there's a couple of other method signatures that

are called configure, but we're gonna do this one first.

All right, so this is going to pass in an authentication manager builder.

And what we're gonna do is we're gonna build up.

We're gonna say auth.userDetailsService and

we're gonna pass in that service that we just made the user detail service and

we're going to make sure that it knows how to decrypt the passwords, all right?

So we're going to say passwordEncoder and

we expose that using a static method off of our entity, right?

So that way if we ever change it, this is where it comes in.

It knows how to do it, it knows how to check things.

So what it will do is it will take the password and

see that it matches our encoded password.

Cool.

Okay, and the other method that we need to override here, is for HTTP security.

So we're gonna say override methods and

we're gonna say configure the HTTP security.

And this also uses a chainable, sort of fluid API.

So we're gonna say http and we're gonna say, .authorizeRequests()

And we're trying to make this as friendly as we can.

But, this is not something that you should run on production, keep this in mind.

So we'll set the authorization, .authorizeRequests() and

say that any request must be authenticated.

Okay, so we're going to say any request must be authenticated, meaning logged in.

The dot here.

[SOUND] Okay,

so this is all chaining and so we're going to say and we wanna use httpBasic.

Now you typically wouldn't do this but again we're just trying to make this

simple so that we can explore it and I can kinda show you what's going on.

And the other thing that we wanna do is we wanna turn off a great feature that you

should probably never do except for when you're trying to do something like this.

When I turn off the CSRF or cross-site request forgery stuff.

Now Spring does this for you, it's really nice Spring Security.

And you don't want to turn this off really, but we're going to.

So we're gonna do csrf and we're gonna say .disable.

And the reason why we're doing that is so that we can easily test in and out, but

do not do that in production.

So again, this is a lightweight implementation and we just use it for

testing, but the nice thing is you can just tweak the setup here, and thanks to

the powers of abstraction, everything else that we're going to write will just work.

Now as long as we've got everything working correctly,

you need to be logged in or authenticated to access our API.

Let's see how we do.

So I want to make sure that our app is running, and that we don't get any errors.

Awesome, and if we come over to Postman.

And we hit our API view on courses.

We should be told that we are unauthorized.

We get a 401 on authorized.

Now that's great.

That's what they asked for.

They asked for every time that anybody uses our API to be logged in.

Perfect. We have done that.

So let's log in as one of your fellow students.

I wanna pop back over to our list and look at the database loader.

Let's grabbed the first student who responded here,

Jacob Proffer the first student response.

So, Jakob Proffer, let's grab his name and his password is password.

Hm.

All right, so let's go and in Postman there is an authorization tab and

there is a type and we're gonna choose basic auth and

the basic auth we're gonna put in Jacob's name and we're gonna put in a password.

So Jacob if that's your actual password you might want to change it because now

everybody knows it.

And we're gonna click update request, and what that does is it added a header.

Okay. So it added a basic header here.

So now we should be logged in as Jacob, so let's see.

Boom, there we go.

We're currently logged in as Jacob Proffer.

Now since we didn't set any authorization yet, Jacob is pretty much able to create,

read, update and delete everything in our API and that's not great.

I mean Jacob’s a great guy and he wouldn't delete Karen's reviews but he could.

There's nothing stopping him.

So let's set up some proper authorization specifically on those deletes

right after this quick break.