Welcome back, everyone, to this lecture that now begins to take a look at the user model and authentication.
So we've set up some very simple views and skeleton code for the basis of our library website.
Now clearly we could take the time to keep adding more view template and URL combos based off our generic
model views or views that we already know from class based views to add more pages.
But we're going to switch gears now, focus on adding users.
We believe that given that you're this far into the course, you could just keep making the connections
to add in a class based view connected to a template and show more information, for example, at a
class based view to list all the authors.
Let's switch gears to focus on adding users.
And the whole point of users is to actually create a user model.
Maybe we could check the current user's checked out books and we want to be able to distinguish which
pages are viewable by particular users.
So we don't want to give everybody just full admin privileges to edit every page or add a book form,
etc..
Let's head back to our code and begin to explore this.
All right.
So I want to actually start off by showing you where Django sets this up for you.
So you'll notice a lot of things will just seem to work right out of the box without us having to import
anything.
And that has to do with the settings Python file at a library level.
And it really has to do with the fact that Django has a built in authentication system and you need
to make sure under installed apps that you have django dot contrib off already to go as well as Django
Doc contrib content types or content types.
These should be by default enabled for you, but go ahead and make sure they're listed under installed
apps.
But for using Django foreign above those should be ready to go by default.
You'll also notice as you go to middleware that there's middleware, it actually tracks sessions.
So there's session middleware and there's also authentication middleware.
Again, that's all going to be operating behind the scenes for us.
And what we're going to do is show you the ability on how to create users for this.
Let's go ahead and start off by doing it from an admin perspective.
So I'm going to open up my website.
So here I am at Create Book, but I'm actually going to go to forward slash admin and now I'm logged
in as the Django Admin Superuser and you'll notice there's the ability to add groups and add users.
So I'm actually going to add a new group of users.
So let's add this here.
And the group name is going to be library members.
So the library members, the people that can actually check out books, that's the idea.
They're going to be able to make a new book submission.
Maybe that would be something for a librarian.
You could also let them actually have available permissions, like Cassie believes an author has the
ability to view a book, etc..
But for right now, we'll leave that all blank.
I'm just going to say, library members, I haven't chosen any permissions and then I just hit save.
I'm super zoomed in so this screen will look something more like this for you.
So I just have library members and that choosing any available permissions you can see the permissions
are essentially automatically can you add change to view up etc..
So we're going to save library members don't need any permissions for them.
We have our first group, you can imagine group being a collection of users.
Speaking of which, let's add now a user trying to click Add on user and now I need to decide on a username
and password.
Clearly later on it should be a person that chooses their own username and password.
For now, I'm just going to say my user.
And then let's give them.
My password has their password so not secure, but that should be fine for our demonstration purposes.
So username, password and password.
Confirmation.
I'm going to hit save.
Hopefully you don't get an error for such a simple password and passwords to common.
So now I'm going to say my password.
One, two, three.
Hopefully it doesn't keep giving me an error.
Otherwise, I'd have to actually think about something here.
So now hit save.
Okay.
Looks like we're good to go.
Okay.
You'll notice that the raw passwords themselves are actually not stored.
So by default, Django is storing your passwords, but it's doing a one way hash on them, meaning it's
using what's known as a s h a a secure hashing algorithm.
256 bit.
To actually perform a one way transformation of the password.
That means it's not storing my users password in raw text.
My password.
One, two, three.
Instead it hashes that and then stores the hash that way.
It just compares the hash version of what the user passes in as their password versus the hash version
of what's saved.
That means if for some reason this library website's hacked, the passwords themselves are not revealed.
You only get to see this hash.
Okay.
Now, if I wanted to, I could keep adding more personal information, etc. but I've already saved the
user successfully.
Now let's go ahead and add my user here to the Library Members Group.
So I simply select the group and I can pass it along with this button here.
And so now it's part of library members.
I could also add permissions.
I could have like important dates like last logged in, date joined, etc..
But now let's just hit save.
We don't really need to do anything else for now.
Okay.
So I have the admin, which is the super user that can come in and change anything they want.
And then I also have this my user notice they do not have staff status and they're part of my group
called Library Members.
So Django provides almost everything you need to actually create authentication pages to handle things
like log in, log out and password management all out of the box.
And that actually includes even a URL mapper.
So let's go ahead and explore this.
So we're going to go back to our code.
And then underneath my URLs at a project level, you'll notice that we already have admin filled out
for us.
Now what I'm going to do is I'm actually going to include the Django dot contrib ofthese URLs.
So I'm going to do it in the following way.
I'm going to say comma here.
Path.
Account's forward slash and then say include.
Django dark contrib the off thought your else.
Now you may be wondering if I already am including catalog URLs and have my own your URL pattern set
up if I'm adding underneath my project level urls this django contrib clips dot are thought urls where
are these URLs set up?
Well, these URLs are set up in the actual source code of Django.
And the question becomes, what does this actually do?
What are the URLs that are available to you?
If you want, you could manually add in all the URLs associated automatically with contrib, the author
URLs.
But long story short, the new URLs that this single line of code adds in are the following.
I was going to paste them here.
It essentially does this for you.
It lets you have all these URLs automatically created for you.
So it does accounts for slash login log out.
Password change.
Password change done.
Password reset, reset, done, reset and reset done.
So essentially, do you want to be able to log in, log out, change your password or reset your password
and then confirm etc.?
All of these URLs automatically get created and linked to when you add in this one line of code.
So we're just going to go ahead and leave it at that.
Now, I didn't mention that.
For example, the accounts for slash log in your URL and view have now been created for us with this
URL pattern.
But what happens if we actually go to that page?
So I'm going to save this change in my early days.
And now let's go to our well, here we are now at the homepage.
But let's go to that.
You are all I said exists.
I'm going to go to forward slash.
Account's forward slash.
Log in, hit enter.
And it's going to say, oh, the template doesn't exist.
Which means while the URLs and views have been created for you, it's up to the user of Jango to actually
create the template files, those HTML files.
That's no problem.
We're familiar creating HTML template files.
Let's go ahead and do that.
It's very similar to class based views where you just have to be aware of what is being passed back
on a default level.
So here's what we're going to do.
We're going to create a new templates folder and it's going to be at a level of the local library.
So instead of templates underneath catalog.
I'm going to say that I have my overall library.
I have catalog library.
And at that same directory level, I'm going to create a new folder called templates because registration
and logging in really doesn't happen at an application level.
It happens at a site level, which is why underneath templates, I then create the default directory
name which is called registration.
It has to be called this.
You could overwrite it, but just to keep everything the same.
Go ahead and do registration.
So I have library templates.
Registration.
Okay.
Then what I'm going to do is up here in registration is where I can begin adding in the templates.
However, as we've done this before, I want to make sure this is actually visible at a settings like
profile level.
So I open up my settings that profile again and there's different ways of doing this.
The way I like to do it, which has done before, is import OS here and then scroll down until you get
to templates.
Remember, I already have the app directories equal to true.
Now I just need to say as we done before os dot path dot join in.
I joined the base directory with.
Templates and that's all we need to do to save that and register that there.
So now the overall project has the capability to view templates inside registration, which is going
to automatically connect to authentication.
So now let's go ahead and create that log in HTML file.
So I have templates, registration, and now I'm going to create a new file here.
And this one should be called log in that each HTML.
And you have to be choosing these names because that's what Django's authentication system looks for.
So what do we do now?
Here is the log in page, which means I need to start checking if the user is authenticated or not.
If not, I need them a form to log in.
So there's a couple of things we are going to typically have on a log in form.
The first one is to check for errors.
So I want to check for errors.
Let me comment that one out.
Expand this.
So I want to be able to I'm just going to type them out here.
I want to check for errors.
Then I want to check if user is authenticated.
If not, I'm going to have them log in.
And then I'm going to need a log in form.
So let's set this up, starting with checking for errors.
This is actually quite simple.
I'm simply just going to need to say if statement.
So if formed errors a form object is passed back by Django, then something happened.
The form didn't sync up.
So it's up to you to kind of say what you want.
Typically, you're just going to say your username or password was incorrect.
Try again.
That is what she says.
Something happened.
The form didn't actually connect with the back end and they're either passing in their username wrong
or their password wrong.
You never really actually want to be specific saying Hey, your username is wrong or your password is
wrong because if someone's trying to hack in to their profile, you don't want to give them more hints
of Hey, your username was correct, but maybe try on the password if you know what I mean.
So we'll just go ahead and say, Hey, your username or your password is incorrect.
Try again.
Up next, we need to handle a couple of situations.
So there's going to be a couple of situations that a user may encounter and go straight to a login page.
So the situations are that the user is logged in.
But no access.
There's a situation where the user is not logged in.
So for example, they go to a page, they're not allowed to see it and they're not even logged in.
We should just redirect them to this log in that HTML.
So we need to have statements for if the user's logged in, but try to access the page where they don't
have access to it.
The user's not logged in so they got redirected.
Is logging that HTML site.
So what happens when your visit website says, Oh, please log in?
So it redirects it to the log in page.
And then the other thing we have to do is the actual form.
So the log in form.
So let's check out what if the user is logged in but doesn't have access?
So if that happens, then Django sent them a stream query called Next.
Essentially go to the next page.
So we're gonna see if next.
So that's something that the authentication system is going to return.
And if they got next ID, so to speak, that means either they're not authenticated or they don't have
permission to see that page.
So that means I need to check for both.
So we're going to say if and then a user object is passed back.
And it has a bunch of different methods.
One of them being is underscore authenticated.
So we'll say if the person got next.
So that means they try to visit a page.
But, you know, they weren't logged in or don't have permission.
If that user is authenticated, that means they were logged in and still got next to it anyways.
Which means they don't have permission to see that page.
So you don't have permission for this page.
So just to be clear, again, if they got to redirect it to a log in its HTML with the next statement
and the user was already authenticated.
It means they don't have permission to see that page.
So that means we have this if statement here.
However, there's another situation that may occur.
So we'll say else and that is they got next ID because they actually weren't logged in.
In which case the user is not authenticated yet.
So I need to ask them to please log in.
And if they log in and get next to it again, then there's come back and see, Hey, you don't have
permission for this page.
So we'll say, please log in to Swift's.
So you see this pitch.
All right, then we're going to say.
And if.
So we're checking out the users.
Log in, but no access.
Users not logged in.
And then clearly we need to have a form here to actually log them in.
So we're going to create a form and then the action, we can actually use URL routing for this.
So I can say go to the URL for login.
So we'll add that in later as a name.
And then the method here is post.
And then finally, what we're going to do here.
It set up our CSR a token.
And then we just need to set up a simple form.
So it's kind of up to you how you want to construct this, but you do get this form object and it's
going to have the username as well as the username label type.
So probably have that one come up first.
So we'll say form that username, that label tag.
So this is just a form object that's passed back by Django.
So they're going to give you a username and then we also need their password.
So let's pass that in as well.
Form the.
Password label tag.
And then form that password.
And then finally, we need an input here.
So we'll say input type is equal to submit.
And then we'll give it a value of a log in.
And then we're going to have a hidden input, which has to do with the next.
So we'll say hidden input.
The name will be next.
And this is essentially just checking.
Does that person actually have.
The permissions to see that page or will they get next to.
So we needed essentially a form Django, by the way.
This person was next to to get to this actual sexual logging page.
So let's go ahead and save these changes and see what happens when I try to go to log in again.
So I now have the template.
If I refresh my page instead of getting that error, I now see something that looks like this.
I remember I already have a user that is part of the library members, so let's try pushing that person
in.
So we'll say My user and then it's my password.
One, two, three.
But we should get an error here.
So it's actually going to take us to another default page for post lock and redirect if you hit login.
Remember, this person exists and it was technically correct.
So that's what we're going to have for a four page.
Four page not found by default after you log in.
It takes you to a log in redirect.
Now, you can actually set up a log in, redirect yourself.
You'll notice by default it takes you to accounts forward slash profile.
Maybe that makes sense for certain websites, or maybe it doesn't maybe actually need to go to the page.
Kind of depends on your web site.
But what you could do is if you don't want to set up the account slash profile, redirect page.
So, again, to be clear, by default, after you log in successfully, it takes you to this page.
Forward slash accounts, forward slash profile.
Or what you could do is come to settings until you find the log in redirect, or you can actually pass
that in ourselves if it's not there.
So let me zoom out so I can see the whole thing.
And it's actually not there by default.
So I'm going to add it in.
So we're going to say.
Log in.
Redirect.
You are l.
Is equal to.
And we'll just have it.
Go to the homepage.
Save that.
Save our changes to log in.
It's HTML and let's try that again.
So let's actually restart the site.
So when I say Python, manage that pie run server.
And then I'm going to go back to that login page.
And you should be visiting this in incognito mode.
So I'm going to bring in now accounts log in.
So here we can see the username and password set up again.
So let's go with this, my user.
And then it was my password.
One, two, three.
Log in.
And now it takes us to the homepage.
So so far we've been able to do is actually use the user authentication system to get logged then and
then visit an actual page.
Not so bad.
We still have a lot of work to do.
However, we still don't know about a log out template.
And there's also things like password reset templates, password reset confirmations, as well as just
testing certain pages against authenticated users.
So right now, what we've done so far is someone can actually log in and then get redirected somewhere.
And our site has this idea that this user is authenticated and logged in.
Now the views need to decide whether or not someone has to be logged in to see the view.
So what would be interesting is if you wanted to maybe see the homepage, you had to be logged then.
So we're going to do in the next lecture is actually add in mix ins or decorators two views to actually
view them and require that that user be logged in.
Okay.
We'll see that in the next lecture.