Adding User Registration/Login To Your Wagtail Website

Okay, hello and welcome to another lesson on learning Wagtail. In this video, we are going to get started with user authentication So we're going to let people sign up, register, in other words. They're going to log in, be able to reset their passwords, things like that. So first things first I'm just going to get into my environment here, so pip nf shell. You're going to want to get into your Docker container or Other virtual environment, and let's do pip install jango all auth. And this is the package that we are going to use to basically get this up and running really quickly. And this is a very well-supported package, so uh honestly it's one of those ones that you can just completely rely on, which is really nice. And then in the browser here, let's just uh let's Google Django all auth.

And let's open up the repo and also the docs. So in here, uh it tells us pip install Django alloth. We're one step ahead of that already. And to actually install this, we need to do a few things. So we need to add Django template context processors to our Uh based up high, but in our context processor. So let's do context processors. There we are. And I already have it in there, but if your app doesn't, you're going to want to make sure you have it in there. Next, you want authentication backends. And what this is really doing is saying, hey, there are different ways to log into your application. The first one is simply just Django. This one is

The one we usually use to get into the Django admin. And then we use the alloth. account. auth backends, that's this one here, authentication backend, to log in with things like email. or maybe Facebook or Amazon or however you want to log in. And so really I'm just going to and follow these installation instructions. So let's find the installed apps, installed apps. And go down to the bottom. And I'm going to add those three lines in there as well. So we've got Django contrib, the auth messages and sites. We already have auth in there messages already in there, but sites is not, so we're gonna keep that one in there. Your site is going to need all three of those as well. And then we're going to add alloth, account, and social

account. And so I'm just gonna throw that at the bottom here. Olauth. alloth. account, alloth. socialaccount. And then if you wanted to, you could add social providers. You're going to need to make an app on each one of these sites, so like if you wanted to log in with Facebook, you'll need to create a Facebook app. And then you would just Go ahead and say, hey, I'm going to copy and paste this into here. You'll have. Specific instructions for API keys and things like that, and yeah, you can just go ahead and do that. We're not going to do that in this video. We are just going to do regular authentication. There's one more down here. The site ID, this is basically saying, hey, you've got uh you've got a framework called Django that can Have multiple sites on it.

Which site do you want to use this for? We're just saying the first one. And if you're using a brand new Wagtail instance, a Wagtail website, it will be site ID of one And then we need to go into our URLs. py. So let's save base. py and open up urls. py. And we're gonna put this in here. And what this is saying is Basically, we're putting all of our Django authentication URLs into the sub -URL of account. So you can go to yourwebsite. com slash account slash login if you wanted to. Now I personally do not like that. I like it to always just be like website. com slash login or log out And so to remove that, just give it an empty regex string like this.

Now we also put this line We put that above this line because it's sort of a catch-all thing. So we're gonna say, hey, if someone goes to website. com slash login Olauth is going to catch that and is not going to try to render a Wagtail page. But if there's no page called login, so let's say this didn't exist, Wagtail will then say, hey, I'm going to look for a page with a slug of login. Does that exist? Yes? Okay, show it. No? Okay, 404. So we put that above the Wagtail URLs. Now let's go back to our terminal and let's simply run our server. Run server port 8000 and one because I know my port 8000 is already allocated. Local host

port 8000 and 1 Looks like nothing has happened. Let's zoom out just a little bit here. Looks like nothing has happened, but if we go to slash login We have a login page. We didn't make this. Django All Auth did. Or sign up, we have a sign up page. And so at this point in time, we actually have a working authentication system. We can tell people to sign up using their uh username, email, and put their password in twice. And then when they're signed up, they can put their username and their password in there and remember me or forget password, sign in, all that good stuff. We're not quite done yet. We have a lot of settings that we can go through. Now before all of that, when you ran your server, typically what ends up happening is it will say something along the lines of you have seven unapplied migrations in red

text. And you'll just you're just going to want to run python manage. py migrate. Now mine 's going to say there are no migrations because I ran this just before recording this video. But yours will say there's seven migrations to apply. You apply them, everything works well. and then run server on port 8000 or 8001, whichever port you want to use. So let's hop on over to the configuration in the documentation. There's a lot of different settings and I'm not going to go through all of them. I'm just going to go through some of the ones that I think are most common. So all of these settings we can literally grab it, copy it, and paste it into our base. py file. So if we open up base. py, I don't know, let's just scroll to the bottom. It doesn't really matter where it is. And then we could just do is equal to true or false or

whatever the string is going to be, or maybe it's none, whatever that setting is going to be. The documentation is actually pretty good So uh account authenticated login redirects. Yes, we want it to login. Uh we we want it to redirect. So let's create a login redirect URL. So for any page that a user needs to be logged in, but they are not logged in, where are we going to redirect them to? We're just going to redirect them to login. I'm just gonna hard code that. There are ways around that, but I'm just gonna hard code that one. Uh user authentication method or account authentication method. Uh do you want people to sign in using a username, an email, or both? I like the idea of both because personally when I sign into a website, I never know which one

I'm going to be using. Is it a username? Is it an email? Is the username my email? So I just always enable both. Account confirm on get So this is basically when someone signs up for a new account, it's going to email them and it's gonna have a special link in there. The user is going to then click that link, it's going to bring them to your website, and then there's gonna be a button on there that says confirm. I don't like that. I think that's too many steps. I think we're asking the user to do too many things. Maybe security is a practice that is really, really important in your application. So maybe that is important to you. But for me on this application, it's not. So as soon as they click the link in the email address, their account is confirmed. Account email confirmation anonymous redirect. So

basically I'm gonna let you read over these on your own. And actually here's what we want to do. I did that backwards just because I got a little ahead of myself there, which happens occasionally. Uh so login URL is going to be slash login and login redirect URL. Let's just make that the homepage if we wanted to. And you can adjust those as you need. Expiration date for basically how long that activation link is allowed to be alive for. Account email required. Yes, I'm gonna say I absolutely want people to sign up with their emails. Account email verification. We've got three options, mandatory, optional, or none. Let's go ahead and use mandatory. So it's always going to send an email address. Or it's going to send an email to the email address that the user is using, saying, hey, click this link to verify that you are who you are.

We can even customize all the login forms, sign up forms, reset password forms. We could customize all those. We're not going to. Account login attempt limit, this is basically anti-brute force, so if you try to log in, let's say five times, that's the default, and you fail, you're going to be locked out for 300 seconds or five minutes You can always disable that, setting it to none. Account login on email confirmation. Yes, if you can verify your email is yours, you might as well be logged in. Account logout on get. Yep, I don't want them to have to submit a form to simply log out. Account login on password reset. Yep, once they password or once they reset their password, I might as well keep them logged in. Account logout redirect URL.

Default is going to be just home, but we could also redirect people back to the login page if we wanted to. Account preserve username casing. This one I don't like because I don't like that Caleb is different from Caleb is different from Caleb is different from Caleb is different from Caleb is different from Caleb. I I don't like that. I like them all to be the same. So I set that to false. Account session remember. That is the remember me section here. And so I'm just going to set this to true. We have two other options though. We can set it to none to ask the user. Hey, remember me or not. We can set it to false to tell them to never be remembered or true to always be remembered.

So if you have a good privacy policy in place, you can just always remember them. Most websites, honestly. also use this setting without even letting you know that there's going to be a cookie stored indefinitely on your machine. So a good privacy policy is always a good practice. Uh account signup, enter email twice. Yeah, no, that's already false. Account signup form class, we can change that. Enter your password twice? I'm gonna say no. I'm gonna say that all my users of this website have never made a typo ever. Uh, account, username, blacklist, this is a good one. I don't like when people try to use my name. Or admin, or anything that might be offensive to other people, such as the word God. I don't want my users to be able to sign up with the username of God, especially if there's forums or a

community or something. You don't want other people to see that username. You could put swear words and things like that as well in there. Unique email, yep. Unique email. If you're using a custom user model, you can also select or tell it to use a particular email field and a username field, which is nice. We are not doing that, so we don't have to do that. Account username min length. I think one is too short. I usually go with three, but let's go with two because that's in the middle. Account username required. Yeah sure. Account username validators, this is a good one. So you can basically pass it a callable or a function. And when someone signs up, it can perform a function to see if maybe that username is too similar to someone else's, or already exists, or is using a swear word So you can do that.

We're not gonna set that up, but you can do that. And then below is all these social settings. So uh you've got a social account adapter and email verification, things like that. So when someone signs in with Facebook or signs up with Facebook, are we going to send them email verification? Question mark? These are a lot of really really good settings. The ones I went over really quickly are really just the most popular ones. So I'm gonna forcefully refresh Django here. So I canceled my server and reran it. And when I go to sign up, I can now sign up. I need an email address. And so I just put a dummy email address, username, and a password in there, and then click sign up. And if we open up our terminal, we can actually see who we sent the email to, what the email message is, and

a link. This is the to confirm this is correct, go to, and then this ugly link. So I'm just gonna copy that. And because we're on localhost, we're developing locally, we are probably not sending emails. And because of that, it's gonna be hard to get that link. So we just open up our terminal and it will be in there for us. So go ahead, paste that link in there, and it looks like nothing happened. And let me zoom out here. Looks like nothing happened, but we said, hey. login whenever we click that link, which essentially we did. And so if I go to slash login, it's gonna redirect me back home because it thinks I'm logged in. Now the nice thing here is if I go to admin and type in my username, test

one, and my password, it's not going to let me in. So I have a user account. It is Confirmed, I clicked the link that would have been emailed to me. And now there's a user account, but does not have access to the admin, which is nice. They're not a super user, they're not staffed, they don't have special privileges, nothing like that. They're just a regular user in your application. And so at this point in time, we're basically done with this, but I think we should take this a step further. So let's go ahead and close that. We need to. Tell someone that they're actually logged in or not logged in. And so what I want to do is just open up my base. html. Let's make that a tad smaller. And I'm gonna copy this UL. And so we can put test in here. Open this up and it's going to say test

in the top right. Cool. Now we need to see if the user is logged in or not logged in. So we do if request dot user. is authenticated It's probably the first time I've ever spelt that right. The first time in my life. So if the user is authenticated, say you're logged in. And if you're not, let's just say something like. Hi guest. And it says I'm logged in. Now I'm gonna want to log in and log out link. So let's go ahead and add those. And at this point in time we're probably thinking, well, where are we gonna get that link from? And we know We know that we could just do slash logout or slash login and that would work and that's hard coding your link and that's not terrible

because that link probably is not going to change but Should it ever change, you might want to use a more dynamic way of doing it, the more Django way of doing it. So let's say log out. And we have a logout link. Nothing fancy. Let's also put our name in here. So let's say hi request. user. username And then ask him to log out. And this should be D inline. Getting a little frontendy here, and that's okay. So that's my username, that's what I signed up with, test one, and it's giving me a logout link Now, that is okay. It's not the greatest way of doing it. So let's head on over to the repo. And so this is just the all-auth repo, and we can actually go in and find the URL.

So if we go to Not utils, that was the wrong one. All auth and then URLs. We can see that it's grabbing URL patterns from the all auth package, the folder called account, file called URLs. And if social accounts are enabled, it adds more. So let's go back up one, let's go into account, and then let's go into URLs. And at this point, we're going to see a bunch of URL patterns, and all we need to do is use that name. So we can use account login and account logout, and that basically maps it to slash login slash logout. And the reason we do this is because in our URLs. py, URLs. py, maybe, maybe we did actually want to change it eventually from just slash login to slash accounts

slash login. And by doing it this Django way, Our URLs, our links will no longer break. So let's go in here and add a URL, a Django URL. URL. Account logout. And we can go ahead and add the same thing in here. But this one's going to say login. And let's go back to our page. Refresh. Don't need to verify my email address. It was already verified. And so it says, hi test one. Would I like to log out? I can log out. It says log in. I didn't add a question mark, that would have driven me nuts. So then I can log in, I can log out, I can do all sorts of things.

So when I try to log in here with my username or my address, my email address I can go sign in and I am signed in. And we can see, hi test, would I like to log out? Now that's nice and all. But on the login page, what if I wanted to adjust that? What if I wanted this template to look a little nicer? Because right now, this is not great, and we have currently no control over this. So let's open up the repository again Let's go back to all auth. We are in the account. We want to go into not the account. We wanted to go into templates. Then account. And then if we could just just open the login. html file and let's do this.

Let's copy all of that. Now we're going to want to put this file exactly in our application where all auth is. So we're going to put it in the templates folder, in the accounts folder, or count folder. And then login. html is the file. So let's open up our explorer, templates, new file, account. slash login. html and paste. Now this isn't going to look like it does anything right off the bat Because instead of saying use the template from Django Alloth, we're saying hey we copied the template from Django Alloth. Use ours instead, but it looks the exact same. So let's fix this one up here. We've got a tab title up here. That does not look nice This is a head title. I know that this one is actually just called titles.

Block title. And I know that because when I open up base. html and go up to title, there it is, block title. So we just need to change that name. There it is. Says sign in now instead of whatever it was before. Let's go ahead and add a bootstrap container around this. So container. Dot row dot coal M D six dot offset M D three. Sure, good enough Let's grab those and then we're gonna indent all of this so it's in there. And this is just again getting pretty front-endy. Save, refresh, and ta-da! It's centered! We could actually even add some margin in there as well because that's pretty squishy.

And there we go. Now let's change the button. Let's go ahead and change that button. We have a submit button, the BTN, BTN-primary. Let's add some spacing so that we can actually see where we're working here. Let's change this from button to BTN to BTN link. Aha! Just like that, we've got sign-in and forgot password. Now, if we go into the signup page, we're gonna have to do the same thing there. So make sure you go into the repo, go into the account folder. Grab signup. html, copy that into your project, and then you can overwrite it with whatever you like. We have a regular form in here as well.

Nothing fancy. It has a CSRF token, form. asp, which is going to basically render out the login form with paragraph tags around each sort of section And that's it. That's all there is to it. Now one last thing we should probably do is open up requirements. txt And let's cancel our server here. Pip show Django dash all auth. And this gives us version 0. 40. 0. We want to add this. I am just adding that in there. And this way, next time you boot up the project and you do pip install-r requirements, you're going to have Django Olof already working in there

And so this was a pretty quick overview of how to install Django Alauth and user authentication with logins and registration into your Wagtail app. This also works with just regular Django as well, because it's a Django package. But hey, Wagtail can leverage pretty much everything that Django has to offer, which is really, really nice. Now just as a quick summary, you're going to want to add your included URLs there. Base. py, we have a bunch of settings in here. You can always reference the documentation for that. We had the request context processor in there. We added authentication backends. We had the site ID of one wherever that one disappeared to. And lastly, we made sure that we had Django Contrib sites, but also auth and messages enabled.

And then we just added these three. And that's pretty much all there is. After that, we just sort of modified some template stuff. I'm gonna leave the front-end stuff up to you. I'm a little more front-end agnostic. I don't know if you're using Bootstrap or UIKit or Foundation or hand rolling your own CSS framework. So I'm not going to get too much into how to make things beautiful, but this is how you generally make Authentication. So that's how we install and enable user authentication in a Wagtail application. My name is Caleb Tallin. Thank you for joining me today. I really appreciate you taking the time to watch this entire video. This is one of the more demanded videos. A lot of people are really asking, Caleb, how do I do this? How do I add user authentication? This is how we usually go about it.

And don't forget you can always hit subscribe, turn on notifications, or leave a comment down below. And lastly, if you really want to, you can come join us on slackwagtail. io slash slack And as always, you can see the entire source code that I'm writing for this whole series, including this video, on github. com slash coding for everybody slash learn dashwagtail. The links are all down below as well And one last time, my name is Caleb Tallinn, thank you for joining me, and I'll see you in the next video.