Though our application doesn't allow a user to update a task,

other than marking it as complete.

We do allow users to add new tasks.

If we look at the controller method that handles this requests for adding.

And that's in task controller, we have add task right here.

We see that it calls upon the task services save method.

Let's look at the implementing class for that service.

So the task service impo.

We see that this class a save method calls upon the DAOs save method.

So let's open that class.

Now this one is simply an interface here that is one of those

spring data JPA repositories that's generated when we boot our application.

Specifically the save method is inherited from the crud repository and

is nice for creating new tasks with all fields populated and even updating tasks.

If we expose to users a way to do that.

The problem is that in order for this to be effective,

we need to have the user field populated in the task entity before saving or

it won't be associated with the user.

Let me show you two ways of saving our task.

Let's start by grabbing the current user in the controller.

So back in the controller, we'll grab the current user.

To do that in this add task method we'll add a principal parameter whose

value will be populated with the username password authentication token object.

Which is implemented the principal interface.

So principal.

Now, we could get the user entity in one of two ways.

The first way is by fetching the user name from the principal,

then using the user service to grab the user entity by its user name.

Here's how that looks.

Let's declare a user variable that's one

of ours not any number of these other ones.

I'll call it user, and I will use the userService

"FindByUsername" and

then Principle.GetName.

If you recall from a previous video, the principal object

will have a method named getName whose return value will be the username.

Now I do see that userService isn't recognized that's because I have not

auto wired it into this class.

Let's be sure to do that.

Auto wired.

private UserService userService.

There we go now down here it's recognized.

Now before we use the task service to save that task we better associate that task

with the currently up then a gated user which is now stored in this user object.

So to do that I'll do task.set User and user.

And now when the test service saves the task,

that user will have been associated with the task.

So everything will be associated just as it should be.

What we should know is that calling upon the userService, specifically its fine by

userName method will result in an additional hit to the database and

note this is not an expensive query to the database it will happen very quickly.

It's still another query to the database.

If we'd rather not hit the database again we can use our knowledge of java and

even run some quick test with output to see

that the principal parameter-- this principle parameter right here--

is populated with a username password authentication token object which

has a get principal method whose return value is going to be the object that is

implemented the user details interface in the typical spring security setup.

So it turns out that we don't need to hit the DB for

our user entity we already have it.

So how do we get it like this.

Let me show you I'm gonna delete what I did here And

will first start by casting the principle to a Username Password Authentication

token object, there's that cast to the principle.

Then we call the objects, get principal method, so all surround this whole value.

With parentheses and call getPrincipal.

And finally we cast that.

to our user object which has implemented the user details interface.

User, just like that.

And there it is.

So this is another approach and it definitely works.

Let's run the app to see if it does work.

I'm gonna open my run panel, and run that boot run task.

And the spring application is booting.

And has now started successfully let's go back here and will need to log in again.

I'll login as the first user that is just user

cool now we've discussed users and roles let's try to add a new task.

Discuss security Great it looks like it added well.

Let me log out from the user account and login to user

two to make sure this test doesn't also show up under user two's account cool.

It certainly does not so if I log out and log back in as the first user.

There it is still there for us.

As I said this is one approach though it's not the only one.

If you'd like to pluck the stuff out of the controller and push it all the way

down to the DAO just like we did with the find all method for getting a list of

tasks using the currently authenticated users ID, check the teacher's notes.

There are options for this.

Well since we now have a to do item on our list for

discussing security concerns let's do that now.

First a word of caution, this discussion is not meant to be exhaustive.

There is a plethora of security vulnerabilities that

need to be taken into consideration when developing a web application.

So please Do your research.

What we'll talk about here are two simple options that add

a nice layer of security to our application.

And that are quickly implemented whispering security.

The first item I'd like to discuss is the storage of passwords.

Currently we've stored passwords in the database as plain text,

such that if a malicious user gain access to the database,

whether through our application or not we'd be in trouble.

Let me show you here in IntelliJ.

We insert those passwords very clearly as plain text.

Even if they're not strong passwords they are stored exactly as entered.

Now should our database become compromised,

a simple query reveals plaintext usernames and plaintext passwords.

As a responsible developer you should take necessary steps to ensure,to

the greatest extent possible, that the data you depend on can't be used.

Maliciously.

Knowing that people often use the same passwords for

many if not all web applications, a data breach might have consequences

that stretch far beyond the boundaries of your application.

In short be responsible developers.

What we should be doing here is storing encrypted versions of passwords

where it is practically impossible to decrypt the encrypted version and

get back at the original password.

That is, it's a one way street.

Now I want to be clear that this isn't a workshop on encryption algorithms, so

you can do your own research as to which encrypted method you'd like to use and

how you'd like to customize it.

In this application we'll use what's called the b crypt hashing function.

Check the teacher's notes for more info on this method.

As spring provides an implementation called the b crypt password encoder.

So let's switch to our security config class and

set that up in our config package.

I will open security config.

Let me collapse this panel here so I have more room.

We'll start by creating a password in code or being in this class and I will do that.

I wanna do that right here.

Not all that matters.

So I'll say public password encoder,

I'll call it password encoder and I will return a new

BCrypt password encoder and we will use strength 10.

Again check the teachers notes and

do your own research as to what this exactly means.

So then back up in this method, in configuring the authentication

manager builder, we'll set the password encoder as follows.

So right after we set the user details service,

we will set the password encoder to what the password encoder being.

Now what will happen is that every time authentication takes place.

The submitted password will being coded.

And the encoded version will be checked against the database

instead of the plain password being checked.

Of course, this means that passwords will have to have been stored into

the database as in coded or hashed passwords.

So we'll need to alter our import.SQL file, we'll need

to replace these values with their hashed versions or their encrypted versions.

Now to get a hash for these passwords, you can hit up any number of online sources.

So let me just switch to Chrome.

And, and I will, in a new tab, Google, bcrypt.

Hash generator.

And I will choose will say this one right here.

Cool.

Enter the String to be encrypt.

So I will be encrypt password.

And there's the hash right there.

So what I wanna do is copy this entire String.

Just like that.

And I want to paste it in place of my plain text passwords here.

Just like this.

Now, whenever I include hash passwords for

initial data, I'm always careful to leave a comment about the plain text passwords

that developers will need to use to log in to the application.

Because he can't enter the hash in the password field of the web app.

So this is just a note to developers.

Passwords are both password.

There's no way for a developer to know otherwise

that this is actually the encrypted version of the password.

Password, so I leave a comment there for development purposes.

Now let's run the application and

make sure it works with our encrypted passwords.

So let me pop this open again I'll stop our previous instance and

I will rerun that boot run task.

Looks like everything compiled correctly.

And after just a couple moments, the application has started successfully.

So, back in our application, let's refresh and

let's make sure that you are using the username and password.

That is the hashed password on the database side,

will still allow me to successfully login and looks like it worked.

So the advantage is that now we don't have users password stored plainly anywhere.

And if a malicious user got ahold of our user table, we can have more confidence

that passwords won't be decrypted, but we can never be absolutely certain,

but this increased level of security is critical.

Alright as a final exercise, let's add CSRF protection to our app.

CSRF or commonly said, Caesar, stands for Cross Site Request Forgery, and it happens

when your application gets a request from a user that the application trusts.

Which is to say in our application the app receives a request from a user's browsing

session which would pass along the jsessionid cookie.

Thereby granting the request whatever authentication privileges are associated

with that jsessionid.

So how can we protect against the damaging affects of this.

Now the first approach is to stop using get requests for

anything that changes server's state.

One can certainly code an application that can change database data or

other server resources from a get request.

But this goes against HTTP specifications.

And though those specs aren't enforced, they are there for a reason.

As for those post requests, which do change server data,

we can add C.S.R.F. or csrf protection to our app.

Let me show you how you can turn this on for spring,

and then I'll show you the effect it has.

So, to add this protection, we'll open our security config class.

Collapse this again.

Let's scroll down to our security filter chain right here and

after the log out configuration we'll continue the chain by adding

and followed by c serve.

There it is right there.

And that's all that's needed to add cserve of protection into our application.

So let's fire this up and see what effect this has had.

I will stop the previous instance and rerun.

Compiled successfully.

And booted successfully, so let's refresh this.

Now we see the same login form that we've been seeing all along.

But it is actually different.

Let's inspect the form and see what has Changed.

If you look at the generated markup you'll see a hidden input right here.

With the name_cerf and its randomly generated value.

On the server this value will be saved in session data and

will be compared to the value that's passed with the form submission.

If the value in the submission is different from the server side session

data, the request will be rejected.

And since it would be highly unlikely that another website open in the same

browsing session, would somehow come up with this value,

this serves as a nice protection against these sea-surf attacks.