In this video, let's try to see in detail about the very first component of user management, which
is user details that we are seeing in the bottom of this section.
I came to the court that we have customers previously and I'm trying to open the user details, which
is present inside the Security Framework Library with the package security dot dot user details.
So if we see here, this is a simple interface which has some abstract methods like what are the authorities
associated by the user password user name?
And at the same time, we also have all possible options that we can have in our application.
Suppose I want to check whether my account is whether my user account is along with the credentials
are experiencing.
That is where we have to force the user to change his credentials every 60 days or 90 days for such
scenarios.
We have these credentials among expert and at the same time there might be scenarios where you want
to lock you up or disable your user for multiple authentication filters.
So for some scenarios we have reasonable and at the same time we can also leverage is action online.
So again, this is just an interface.
Suppose I don't have a very big application where there is no need for me to create my own user schema.
In such scenarios.
We can go with the sample implementation provided by the Spring Security Council, which is user.
So if you see here, they also put in the commands, see the user for a reference implementation.
That means in a scenario where I don't have a major requirement and I'm good with whatever spring security
schema is providing like user name password authorities, then we can leverage user class privacy here.
User class implements our user details.
It has variables of password user name authorities and the booleans, which indicates whether my account
is active or not.
We have to make sure these variables names should not be changed because these are the things that I
understand by our spring security.
That's why whenever we create our own custom class implementing user details, make sure you're adhering
to the same naming conventions and name variables.
So once we have these declarations, we have a constructor where someone wants to create a new user,
bypassing the user name password.
And authorities post that we have another constructor inside the same user class.
The difference between this constructor and the upper constructor is we pass on the boolean details
also in this constructor, whereas in the upper constructor we just pass mandatory details like username,
password and authorities.
And by default, spring security will set all other boolean values to prove that means.
Is my account nonexperts true means?
That is not the same.
It is my account nonlawyer.
That means when its value is true, which indicates account is not.
It's a positive scenario.
That's why by default it is setting to do so that our user will be processed with the correct username
and password is provided.
But if we have a scenario where you have your own logic of determining whether a country's non expert
or non log from the value stored from your database, you are free to parse those details.
Also, accordingly, the user object will be built using this constructor.
So whenever we are using these constructors and trying to create an user object of user details, interface
implementation, we have a getter methods which are essentially abstract methods inside this user details
interface.
And all those abstract methods have been implemented here by retaining the values that we received when
we are creating a user object using its constructor.
And at the same time this user class, which is by default implemented by our spring security, people
having builder class, also user builder class.
So we have a user builder in our class.
Inside this user, the purpose of this is if we want to create users, we will leverage this user builder
class like we have discussed in the previous videos.
If we go and see here that we have implemented first, my application is very simple application and
I don't want to define my own implementation of user detail, that's why.
I'm going ahead and using the default implementation provided by the spring security, which is user
and with user, I'm trying to create with the username password authorities by using the bill.
So this is one of the the other way is by directly calling the constructor with the values, bypassing
the constructor arguments.
So there are two ways, but here we have implemented one.
So right now we understand completely about user details, interface and the default implementation
of it, which is user.
So it's very simple.
If we are good with the default schema provided by the user details interface inside spring security,
you are free to use the user class implementation.
Otherwise, if you want to have your own blueprint or schema for your application, then the customization
has to be done by implementing this user detailed interface.
So with this, assuming it is hoping to you about the user details interface, which carries the blueprint
and schema of our user inside any application.
Thank you.
In next video, we will see about user details, service interface, which is the very next important
component of user data.
Thank you by.