OK.
So back to visual studio we'll look at firstly our icons controller and I mean we could sit down and
dissect everything that is here but what I really want to point out are the fact that it does have actions
for the log in.
It does have a GET and POST action where it validates who is the person logging in and then takes an
action.
It's just a bunch of statements that we're used to.
And then you get some other code because remember it's not all about verifying or validating against
a local database but it also gave us code to allow us to register and sign up for an application using
social media accounts for this video.
However we're going to simply look at controlling registration and log in using our own local database
and what we need to do in order to support that.
Now let's systematically go through all of this code.
All right.
So the first thing to point out is that in the models folder you would have gotten some model files
particularly identity model not C.S. identity models.
That's yes.
And this file would be either initialize it for the entire identity engine which is what controls I
use the authentication engine.
Right now this user authentication engine actually automatically creates a database for you at least
if you don't already have one if you already have one then it takes a bit of configuration to ensure
that you are going to be pointing to the database that you wanted to point to in our model file.
Identity models we'll see that we have two classes.
Application user and application DV context and application DB context points to some connections string
called default connect so what happens is that once you generate all this code and an identity engine
it actually will generate a database for you on the first launch.
All right.
And this database will be generated based on the specifications set up in in default connection.
So we can go to solution explorer and take a look at the Web config file.
That's a Web config.
And the last one here that is at the project level there is another one here in the view's level that
is not the one you are to be looking at.
So the last Web config file that is in the project let's go both of the project.
It will have under the connection strings section in line 12.
It may vary but you'll see a connection string here with the name default connection.
And if you take a look at what is in the connection string value you'll see it has a quite unique looking
value there.
And what it is doing is creating a database that has the same name as your project.
And it will use that as the engine for your identity functions.
Now if I take a look at server Explorer I see that I indeed in fact do have a database set of default
connection and in brackets school management and you'll see that it has all of those tables right.
It has quite a few tables and I added a few tables there afterwards.
But don't mind those.
You should see at least these.
But that is not necessarily what is desired because we have already been working on our database we
are at this point because we are doing database first MVC five developments.
So indeed in fact what should be used to hold our identity tables should be our database that we have
come this far with which is housed in the school management on a square D.B. entities connection string.
And if we look at this connection string we see that it is indeed and in fact pointing to the data base
in our local EBA called school management D.B..
That is the database that we really want to be using to house all of our user interactions are user
authentication and the various user based functions.
All right.
So the first thing you want to do is change where this is pointing to an I already have that line of
code.
I did this all right.
And I'll walk you through it.
So just comment this line and on Comment this line and I'll walk you through the changes I made that
took everything out of the data source and then I replaced it with the values coming from the data source
here so I looked in my entity's connection string and I scroll across until I saw data source.
So we have connection string is equal to and then we have data source and then I took everything here
from local D.B. sorry right down to the last one I don't think you need everything but just to give
you some clarity.
And then I used that value and paste it here in data source right here.
So at least the two of them are looking to the same point.
And then you're probably going to ask so why not just change the connection string that is being referenced
inside our identity model.
No.
The problem with doing that is we're using entity framework and identities does not play well with this
flavor of entity framework.
So it will actually give you an error if you try to replace the connection string that identity model
is using.
You can try it and see the error for yourself and if you have had any success with it that would go
contrary to what I'm seeing then drop me a line and let me know when we can have a discussion about
it.
But my thing is I just kept default connection I could always rename its books.
I have to make sure it matches a connection string here in this config file and then I changed out the
value in connection string to point to my database.
Now having done so once you go into debug mode it will then one search for whatever database.
So in this case since it didn't exist it's actually created this database at the time.
And then what it will do if the database is found which it will be in this case is go ahead and generate
those tables.
So if I look back in server explorer and look at all the tables you'll see that I know have all of those
tables created here.
And if I look inside of is being that users by clicking and viewing the data
I will see that the user I just created is right here.
The idea looks a bit weird because we're probably used to that auto incrementing This is what you call
a Jew idea good or very unique ideas value.
All right we have the email address and we have a few forces but look at this.
Look at the password.
This is not just a password but it's called a password hash.
Look at it.
Take a good look at that.
It is always good practice to encrypt your passwords so that somebody by any stroke of luck got to look
at your database and look at their users record as much as they can see the e-mail address.
They should never be able to make out what this password is.
And if you look at what comes up in that tooltip you see that that is a full value of this password.
It is completely unintelligible to a human being.
All right.
And then they have a few other default carloads that go in and you see the user name is automatically
set to whatever the e-mail address is.
All right.
So that obtains for every user that you create.
You see that they also have support for rules.
I don't have any rules.
Now let's get back to our model application user.
Now the challenge with this auto generated code is that it doesn't necessarily capture all of the data
that we want to capture based on our context.
So for instance I'm doing a school management system if I'm going to have users I'm going to definitely
need more than email address and password for my users.
I'm probably going to want a date of birth for my students and went to once and I dress for my teacher.
So I will I'm going to want additional information.
All right.
So we need to be able to modify our context or our model that is governing what a user looks like to
our application.
No there are a few changes that will need to be made.
The first one is with application user.
So we want to go ahead and add the property dates of birth to this class so I can just write up in Visual
Studio and press stuff twice.
And that will generate that line.
I would want that date of birth to be a date time data type and I would want it to be birth date and
then I can just use this clarified that using system in order to get our date time to recall.
You have to use certain libraries to get certain class types.
So we know have new property in our user called Date of birth or birth dates rather.
So that is modification number one under our belt do know to add as many properties as you need and
be sure to use the correct data type as you see you need to when you're storing the data because whatever
data type you're going to use here in C sharp is going to be translated over into our school for further
storage.
So be very very deliberate with your data types.
The next step is to make what you call a migration or a change to the database.
Now we've gone through making changes to the database we saw that we just need to go into our SVOD explorer
bring up the table modify it and then update our DMX.
The problem here however is that while this EDL mix has not been updated to reflect the new tables and
to making the change just like that does not necessarily mean that application is going to know what
to do
now we need to run a migration and to do that we're going to have to get our hands a bit dirty with
our console which means this is one of those things that can just click and generate.
You'll have to write a bit of code here to do that.
So we will want to write some code to enable migrations and further on the migrations using our package
manager console.
I have it here on Dr. toolbar already.
But then if you don't have it there or anywhere visible then you can always go to Tools and then go
to New get package manager and then you just click package manager console and that will generate this
console.
So I'm going to.
So I could add my console of any messy era that was there and then we will look at enabling migrations
first and foremost.
So we'll write enable dash my creations.
Press enter and then I'm actually going to reproduce that error that we just saw.
So this arrow is saying that we can't have a migration being done in ambiguity because I have more than
one context the other context it doesn't know which context or which database connection or remember
that we had to connection strings as told by our web config file.
That was a wrong one sorry.
In Web config we had context number one context number two.
Or rather we had context number one application DB context as well as context number two.
Do remember that this is a database context in waiting enable migrations is saying I don't know which
one you want to use this command on.
So we have to be a bit more specific.
So they actually instruct you as to what to say.
They see use and they see it for both.
So more than one context to respond to Niblett for the application DB context then we need to see enable
migrations for this at that and then if we wanted for the entity's context then we need to enabling
for that.
So I would want it's on the application DB cleantech since that is the one that's read and truly we
are identifying as our user management are context.
So I'm going to see here enable migrations I can just press up to see the last command and then I'll
see Dash context
type name and I just press tab and it generated that line and then I'm just going to copy and paste
this part to reduce the margin for error application context D.B. and this press enter and see what
happens so that operation may have taken a while but then we'll see here that's completed and we've
got a new file configuration that see us.
And we also have a tiny warning here saying that they detected that another migration may have occurred
but the end result is that we have enabled it for our project.
All right.
So the next thing we want to do is actually register our migration So migration is pretty much like
making a change to the database.
You'd make a change to the database.
In this situation though we're making a change to the model that is generating the database so open
to this boy web generated models based on the database.
These models are generated based on the database.
In this situation the database was generated based on application user model which is inheriting from
identity user which is where all of those default tables and columns were generated from.
So we actually modified the base model.
So we need to inform the database that the model that it should emulate is now updated.
And this is a principle in code first development we're doing database for as developments.
So it called first development.
That is how it is you build them based model and then you generate the database based on that.
So in this situation we need to let our database know that we've made a change or we're going to add
a migration.
So I'm going to add dash migration and I'm going to name it added birth date.
That is the name of this migration that I am registering so I'm just going to press enter and then this
is also going to do a little operation.
And when this is completed you'll see that you would have gotten another file.
And just to take a look at where these files are being stored you actually got a new folder called migrations
and then you see all of those migration files being listed there.
So each time you add a migration then a file is generated just to keep track of the changes that are
being made.
The good thing about this is that you can roll back to a specific migration in case you think you may
have botched your data model or you've made a change that was undesirable you can just roll back your
migration and it would undo the changes to your database.
So this code first methodology does come in handy when you're dealing with a very dynamic project and
you don't necessarily know what your database is until you are developing the feature.
So this works well with a more agile approach than having the database and building our own database.
That being said after we get this file the last thing we need to do is actually update the database
so we see updates dash database and then press enter.
All right.
And then we get a bit of verbiage seeing that we can see of the dash database space dash verbose and
that would show us all of the obscure statements being applied to the target database meaning whatever
statements would have been used to meet that change and add that column but the end result is we see
seen or at writing so we can assume that we have no errors and that we can always go back to our server
explorer and refresh our table and voilà there is a birth date added to our table so you can do this
with as many other columns as you see fit.
I'm just using birthday today as a quick example.
Once again you simply add your column here or as a property or other and then you run a migration.
The great thing is that you already enables migrations so you don't need to go through that step again.
What happens here after is that each time you make a change you have to add a migration and to its name
what migration was done and then you run an update command and that will keep track of all of your changes
as you go along because you know your project may expand it might contract your requirements change
and you need to be rather dynamic with what you're storing as user information.
So that is how you go about customizing this identity model to what you may need in order to complete
your task.
No where have about two more steps and then we can call this relatively completed the fact that you
added this to the database does not change the view.
So remember although we update the model we still need to modify our view to be able to collect this
information and there are a few more steps that need to go in in order to accomplish this.
So firstly we need to understand where what is stored.
So remember all views are stored in a views folder in a folder that corresponds with the controller
that it is related to.
So we have that Collins controller for user authentication so we have that ConEd views folder for all
views related to that and then we do have or register page now already start page is what asked those
for the user name which in other words would be the e-mail and the password and then it ask for a confirmed
password as you see there is some configuration some generated code in the book and that gives us the
the comparison between the password on the confirmed password before it actually accepts that data you
can attempt to have mismatched passwords and see that validation message that comes back.
And remember that must validation message will come back on top.
Here are the set of them would come back here.
So what we want to do is add birth date as a field so I already have email.
I would probably want to select or collect the birth date right after email so I can see it as the birth
date and birth date.
But then you would notice that there is no birth dates coming up in the intelligence because our model
does not know anything about birth dates.
So I'm just going to put it there and we see that as a red line because our model once again does not
know what birth date is.
If we look at what the model is we'll see another country's new construct being introduced called a
view model.
So it's really just a model like any other class that we've seen.
It's just that the view model the principle of view models is that you the developer can actually customize
a class that helps you to add your own data and notations and validations and so on and then you pass
it on into the database or match it back to the model at will.
I would have to do an entirely different tutorial on that view model point of view and perspective but
then let's just beer through this one and hopefully connect the dots if not you can always watch that
video.
So we need to modify our view model so that the page will know about birth dates so if we just control
and click on the register view model we'll be navigated to it and it is really being hosed in a file
called a ConEd view models so in solution explore if we go into models we see that we have a ConEd view
models all right.
And then if we open that file we see that we have quite a few models view models rather that kind of
have the same names as some of the views that you would have seen in the cones controller.
All right so you have verified code view model you have verified code view you have for got view model
if you look in solution explorer you have a forgot or forgot password views are so read entry level
view model is more of a specific type of class that you create and you can set up your data annotations
are will you see that there are quite a few data annotations that would validation and what is displayed
and that gives you greater control over how you generate your view and what you display on it versus
the view coming the model coming back from the database where you kind of have to work with what you
get kind of vibe.
So this is a far more flexible way for you too.
It's a bit more work but it is a flexible way for you to manage your views.
So if we look at our register view model we see that this is required.
It's an email address the displays emails so we all know from our data annotations video that we can
change what is displayed here.
All right.
Email address slash user name since they're doubling all right.
So I can say email or just slash user name and that would change that display and we have the property
email.
So what I need to do in order for this view model to normal birthdate is added here as a property.
So I will go down.
So I'm going to make the birth date mandatory.
So I'm going to say are required.
I'm going to specify the data type so you have some default ones like this.
That's an e-mail that just attributes but this one I'm going to have to use my data type.
I think these are knows so data type and then open and close parentheses and then set up those parentheses
as the parameters I would say data type dot date time and you'll see they have quite a few ones coming
up in the intelligence so you have all of those that you can use if you need to add that kind of validation
to whatever field you're able to put in.
So the data type must be of type the time and the display will be.
Date of birth.
And once again this is where that display name comes in because I'm really calling this birthdate so
it is of type it time and it is birth date.
And then once again I being through the library for Date Time which is using system.
Having done that the narrow line will go away because no our model knows what birth date is.
And then the final piece of this puzzle is to modify or a cone controller in our register post option
where it is actually loading up our model to send off to the database.
So we see var user is equal to new application user or Amber where application user is coming from.
It is the class that we just added.
Birth date to application user.
Birth date.
So we need to update this creation model description of an object of application user to see user name
email and then either edit it.
So that's what it would be but we don't want it to be daytime but no we'll just add it on and say birth
date is equal to model
dot birth date.
So remember that once the post option once we get the view and then it is submitted it turns over to
the post action the post.
Action is then receiving an object off register view model called model and in this register view model
or model object called model we are using the corresponding data fields to fill out these properties.
So that means I could easily add another field here and call it a user name and then instead of using
the email address for both email and user name we can see a model dot username after adding an appropriate
text box or collection section for the user name.
So whatever modifications you're going to make to your application user model you have to also make
it to your register view model then the register view.
In order to have synchronicity there.
And then finally or a current controller and all of that can't be done without doing these migration
steps.
So I was actually in the notes right out the steps towards filling out or completing all these tasks
step by step.
If you follow those steps then you can't leave any stone unturned.
So to wrap this up let us make sure that the changes that we made are reflecting in the functionality.
So once again I mean the chance of data annotations as it emerges.
This is a name known to use a shadow of the same email address or user name.
If I try to register then we will get something about the dates of birth field being required because
we set up that data annotation and the passwords do not match because there is also a generated code
or annotations that govern that.
So all of those things are in place the dates of birth really and truly you want to use.
And the picture here.
You don't want to have dates of birth just being a free text field as much as it's a date time and it
will not accept that but then users will try to type in the date according to how they think they should
look.
Some people see year month day.
Some people say year day month some say day month year et cetera et cetera et cetera.
So you want to use a calendar because enforce the standard from right here as much as you can.
But I won't go into that right.
No I'll just write a very generic kind of random date and I will use a password test password and it's
more they'll know that you can use data annotations to actually govern how strict these passwords are.
That's a mismatch.
Also that metric.
That is a mismatch so type in a password and then press register.
So it does actually click register and see what happens and then it gives us that standard about that
password so let me try that again test.
So the password is capital T capital P test password 1.
All right so we have at least one digit and we have at least one upper.
I give it to so we shouldn't have a problem.
No.
All right.
We see that we progressed beyond that checkpoint.
And if we take a quick look in our database just quickly bring it up or solution explore
drill down into our tables into our databases and then into our tables
and we look at the data and is being net users.
And there we have it.
We have the user that was created earlier and it got a very generic birth date because the birth date
field can't be no.
Then we specify that in our database design.
So it's not no.
And so we've got a very generic birth date.
And also we see here that the one we just created actually got the birth date that we put in.
All right.
So those are things that you can do to make sure that you're capturing all of the required fields according
to your context and application and customize the speed on its user identity engine.
All right so thanks for watching guys.
I hope you learned a lot.
Once again if you are unsure about anything.
Drop me a line in the comments and I'll be sure to get back to you as quickly as possible.
And in the next video we'll be looking at how we can go both restricting access to certain parts of
our application.