Django User Model: Past, Present, and Future with Will Vincent

So

Speaker 1: everyone, thank you for coming. I know it's near the end of the conference. This talk is about Django's user model, past, present, future, and why are we talking about this? Handling users is one of the biggest areas for any website. And the user model sits at the heart of how Django does it, covering authentication, authorization, and profile information. The user model manages all of this, and it must do so in a way that's performant and secure. It's one of the very core batteries in Django. Remarkably, the user model itself is essentially unchanged since Django's first public release in 2005. This is in spite of the dramatic changes. In the World Wide Web during that time and in to Django itself. Django has a repeat

Speaker 1: framework, but there's double-digit PRs being merged every week, major release every eight months, monthly security and bug fixes. And so on, yet somehow user has remained the same. So in this talk, we're going to look at the history of the user model to understand the design decisions Django's creators and core developers made About two decades ago, look at changes around user, most notably in 2012 when there was a big discussion which led to custom user models being introduced in Django 1. 5. And then we'll look about look at how to use user today and some thoughts on the future how we might even improve it. So I got an introduction. This is who I am, educator. I do a bunch of stuff. I don't even really want to talk about all this. But the important point is I spend a lot of time talking to beginners.

Speaker 1: And also with people like Carleton and Jeff Triplett who are pushing the boundaries of what the framework can do. So that's my perspective. A lot of people here have a different background, right? They work at consultancies, startups, big corporations, universities. And so the Concerns and attitudes I have are based on my experience, but this confluence is how we are Django. Alright, so how do we get here? So I had a lot more information on Django's origin story before I knew that Frank Wiles was going to give an entire talk on it. So I will skip most of that. But this is the Lawrence Journal world, which is where Django started Back in the day, about twenty years ago. And Django's tagline has always been for perfectionists with a deadline, which I think is important to understand that it's meant to get stuff done.

Speaker 1: It's not a side project, it's not some abstract exercise. Django from the beginning has had real-world constraints and demands. And building a web framework is all about choices. Overall, Django obviously got it mostly right, or we wouldn't be here. Um Jacob Kaplan Moss gave a talk in 2017, a PyCon tutorial called Let's Build a Web Framework. Where he talks through all the foundational choices any web framework creator has to make. And essentially it's all about trade-offs. I'm not going to say it depends, but it sort of depends. And as much as I'm going to point out some shortcomings in user, again, I just want to highlight how right Jacob and the other members of the Core team and core developers got it right back in the day. So let's put on our time travel hats, go back to 2003 and make some choices about what we're gonna do.

Speaker 1: So this is the web back then, right? AOL and Yahoo. These are two of the biggest websites in the world. And how do they handle users? Username, password, right? Back then, and it's hard even for me to imagine, and I was alive then. People didn't have email. We certainly wasn't ubiquitous. We didn't have mobile phones. We didn't use it for online shopping. Username and password was the pattern. And you know, you probably didn't have a hundred passwords for everything, right? You just wrote it down in your sticky note and you were good to go. Also, email was really bad for a long time. It's full of spam. It was slow, hard to use. So username, password. Then this site came around, 2004. This is one of the very first that I'm aware of that started with the email password pattern And again, I think it's because it came out of an academic context where you were given an email address, right?

Speaker 1: Like Gmail didn't come around again till this year. So it was starting to happen. It wasn't completely uncommon, but it was probably not a choice any of us would have made in 2003. All right, so these this is the fields that are on auth. user. And there's 12 of them. You can see back on GitHub the initial um commit that where Adrian Holavati brings it over from SVG. It's all right there. It's the same fields. And it's worth looking at them just for because we're going to talk about them during the talk. So Username and password both have little asterisks. They're the only required fields. Obviously, we need some way to have identify and authenticate someone. But then we have all these other ones. First and last name that everyone or some people here are very familiar with. Email groups, user permissions, staff

Speaker 1: active, super user, login, date joined, these all make a lot of sense if you're building a newspaper CRM and It's unsurprising that they're there, but I want to dive in a little bit more into them. So specific because the user model does a lot of things. That's part of its power, but also part of the problems. So authentication, who are you? You only need two fields. And again, they're the ones that are required , but we get a lot more. Five of the 12 are what I would term profile information. So information about the user, first, last name, email, last login, date joined. It's pretty obvious 20 years on that this is a little problematic. Obviously, first and last name is a very Western-centric and doesn't fit uh Django 's global audience.

Speaker 1: Russell Keith McKee has a whole talk on this from 2017, PyCon Australia, I recommend looking at. And also, user is tightly coupled with the Django admin. So you can see this information when you first log in and look at users, which is helpful, but also means it's hard to change. This is the third piece, authorization. What can you do? Again, five of the 12 fields. And this is permissions, groups, staff, active, and superuser. So, what are the issues here? The main one is a lack of separation of concerns. We've got three things bundled together in one user model. And For many websites, this doesn't matter in terms of performance, but if you're a really big website or you want to handle newer forms of authentication like PASKIS and social auth, this is less than ideal.

Speaker 1: And we'll get into that a little bit. So I don't need to do this necessarily for this audience, but just for the anyone watching online, the reason why some of this performance stuff matters is because of how authentication works. So quick overview. We're using HTTP here, hypertext transfer protocol, and it's stateless. So every request doesn't know anything about the past requests. So when you first authenticate, you get a session ID stored as a cookie on your local device. And then this session ID is passed back and forth through every request. And again, authentication is an area where security really, really matters. If any of this was wrong in any way, we'd all kind of be screwed. So we want it we want it to work. And then but importantly, we want this just to to work if we're using a web framework, right?

Speaker 1: The whole point of web framework is to be b add batteries and get out of the way for everything else we want to do. So contrib. auth actually has eight whole sections on it. Um we can take user models just the first one. We can look and see there's attributes. So this would be like is authenticated, is anonymous. There's around 15 different methods, uh including get username, get password, manager methods. So this is for performing common um operations such as user creation, querying, permission checking. Permission and group models for controlling authorization, which again is bundled in and is technically separate from authentication, but we get it all included. Signals for login and logout, so you can get notifications when these events uh occur. And then finally, authentication background to determine how users are verified and retrieved from the database.

Speaker 1: Okay. I've written a lot of tutorials on Django, and by far, probably 75% of all my traffic comes from one tutorial on how to do basic login and sign up with Django. Because it's not demonstrated in the docs and it requires, I think, too much configuration for a new project. I want to quickly show how you do it, and then we'll talk about how maybe we can make this better. So when you do a new project with Start Project, there's a list of installed apps. You can see authors right there. Great. Move along. What do we have to do? We, as developers, have to add it to our URLs. py file. You can do it with this code, which I won't necessarily walk through. There's no login template by default, which we should have.

Speaker 1: So you have to create one. And you have to know that you should create it in registration dash login. html because that's where the login view is going to look for it. This is a super basic way you could do it. In this case, we've created a template level templates folder within it a registration folder and then a login HTML file. That and this is as basic as I can make login be, and we're using a CSR CSRF token uh because it's a post request. And this is mostly what it's going to look like on a new site, right? There's no fancy design like, here we go. Thank you, Django. So it's not bad, but it's pretty minimal. Now logout. Everyone needs a logout link, and it used to be until Django 5. 0, you could just have a link and do a GET request for it. Now it has to be a post, so that requires using a form.

Speaker 1: So this is Again, about as simple as I can make it to do a logout thing. It's not so bad, but if you're a newcomer to Django, I think this is off-putting, right? To have to see this when you just want it to work and you want to get on to the next thing. But signup's not included either, so you have to do all that. I haven't even shown the views, the URLs, and the template to get you this, which You can learn how to do it on my Learn Django tutorial or anywhere else, but again, I think it should be included. And this is my main point. Like this is kind of crazy if we all step back that we don't have these things in Django itself. We should have basic login, logout, and sign up. We don't have to promise users it's the best ever. We certainly make a lot of other choices for the local config that aren't ideal in production.

Speaker 1: But we just should have it and not make people even look at author authentication when they get started. And it's not hard, right? We don't have to change the user model. I'm gonna talk a bit about if we wanted to what we would do. Like this doesn't touch Octhod user at all. It's just a matter of docs and updating start project a little bit. So I'd love to talk about this more later. I even have an open source Django project starter project, Django X, over 2,000 stars, that basically does this. That's kind of all it does. It's a start project with auth that works. Um shouldn't really be a need for that, I don't think. So let's look at what happened in the community. I'm digressing a bit. So in 2012, there was a huge discussion about all this. This is around when I started using Django. So I actually didn't know any of this until about a year ago

Speaker 1: when I started researching this talk. And three big problems emerged. Oops. So need to log in with email, not username. I think that's pretty common pattern. But even, you know. 12 years ago, that was a common pattern, and everyone was like, we need to do something. You need to associate profile data with user model in some way, some consistent way, I dish uh ideally. And then it was clear that first and last name was an anti-pattern. So there's this fantastic wiki that Russell Keith McGee put together in 2012 that again, I'll be honest, I didn't know about Django 's wikis until two years ago. Actually, show of hands, who knows about Django's project's wikis? Can I see? So even here that's less than half the room. There's so much information in there that people have taken the time to compile for posterity's sake, including this, where

Speaker 1: this discussion happened, you can see it on the um Django developers heat mailing list, but things got pretty heated pretty fast. And Russell put this together. There are basically five approaches around we should do something about the user model. So the first one was super minimal update. Um at the time the username field was required but limited to 30 characters. You need more for email. There's nothing around being required. So this was like the bare minimum we could do. Solution two was something around adding an auth user model to settings. There are actually five different approaches, A, B, C, D, E. But that was the basic idea. Third solution was to refactor the app entirely. There was a Google Summer of Code 2010 patch that attempted to do this.

Speaker 1: Fourth option was just throw it all out and do contrib. new auth, similar to what happened with forms, where you went from forms to new forms. That's certainly appealing, but probably the most work out of all the options. And then the fifth one is to pair things back, have a simple profile-based single-user model , as minimal as can be, and profile objects stored for additional information. So how you know even today, I don't think we would agree and find consensus on us to solve this. And back then, they didn't either. So uh Adrian Holavati is one of the creators. Chimed in and said he just writes everything from scratch. So he doesn't even use any of these. Jacob liked approach number five, and everyone fell somewhere in between on the uh discussion.

Speaker 1: And essentially it comes down to these three universal concerns, which we can agree on, which is so what do we want to do, right? We want a user contract. We want common ground and what user can do, which most people would agree should be as minimal as possible. You just need s some way to identify and some way to um uh identify and base pay password to confirm that person is who they are. You'd like a separation. We don't need the permissions API on every single user object. And forms. If a form is created on user The exact contents are unpredictable and that can cause problems because you could define forms that conflict with user reference fields that don't exist. You don't want to give a user too uh Django developer too much rope with which to cause problems for themselves. Again, this is like a very deep core battery

Speaker 1: most people shouldn't even touch. And so ultimately there was no the community could not reach a decision. A BDFL benevolent dictator for life decision was called upon. We used to have Adrian Jacob in that role. And they chose 2A, which was essentially a custom user model, which was added and uh ticket 3011 and added in Django 1. 5. So this is how Django used to get things done. And it did improve things, I think. A lot of people like custom user models. But it's not perfect. So let's talk about where we are today, in my opinion. So we'll just add a custom user model, right? Well This is at a minimum the five steps you need to do that, right?

Speaker 1: And you have to do it before your first migration. So You can migrate it, but it's a little bit thorny. You don't want to do it. So I'll just quickly go through these. So you need to create a new app. I've called this one accounts. Add an auth user model. So we're saying dot custom user, we're gonna create a model for that. Create a model. Again, I could do a whole talk on on this. I'm just gonna kind of go through it a little quickly. But here we're using abstract user, which includes everything on the normal user model except permissions. It adds them with a permissions mix-in. This is the safe approach. This is the approach I think people should use. But you can also do abstract base user, which is a step below, which just gives you password and last login for a password refresh token. And you can, you know, you can get rid of first and last name, you can get rid of user

Speaker 1: if you want. So um I don't recommend doing it, but a lot of people in this room I think have a pattern that works for them and repeat it in every project. And notice that pass there, right? So if you create this, there's a big pass saying put extra fields here. Right? You don't have to, but you have something there. We'll c we'll come back to that. Update the forms. Everything's tightly connected, so you have to update user creation form, which um is used for creating new user accounts. You also need to update user change form for Updating, changing existing users. Um again, I'm just gonna kind of show this. There's a whole tutorial you can look at if you want to see more comments on it. We have to update the admin, right? Because everything's tightly compiled. So we have to add our new user model and the forms.

Speaker 1: And again, I think this is the fact that this is the bare minimum, it already like I'm already talking too much. It feels like too much to have to do. And then you have to migrate it, right? And have this be the first migration. Don't you dare migrate initially to get rid of all the unapplied migrations after start project. So You could also use a user profile model, which is not currently talked about in the documentation. We'll get back to that. So this is where you use the original user model. And then extra fields, you do a one-to-one relationship on a user profile model. In larger projects, you can have multiple profiles. So to get whatever you need about the user. So if you have 40 fields about the user, maybe you only need 10 fields in a settings page and a different 10 in a shopping cart page.

Speaker 1: You can just get the ones you want, so that minimizes the bloat. So I think that's a good thing. But effectively, this is where we are. This is a map of a choose your own adventure book where you read through and it asks you one thing or the other, then you go to another page. This is the process for people certainly new to Django, and I think many existing Django developers with authentication. And the problem is there's the docs don't provide one answer because we as a community don't have one answer. This is still an unresolved thing. And that's a problem for a core battery. It could be fine for a peripheral thing, but for a core battery, I think that's off-putting Django is often considered hard to learn. I know this, I write books on this, make my living currently doing that. I think auth is one of the top three reasons why. Because you have to add this to a website and look at all the forums and all the discussions that you just wanted to get a website up with some

Speaker 1: login and and sign up. And if you consider the progression of someone new to Django, so you learn about the user model, you learn how to write your own login and sign up pages. You don't fully understand it, but okay. Then later you find out about the custom user model and you find out dire warnings that you screwed up because you already have a migration. Like that's a really bad flow, and that's I think the majority of people new to Django, that's their ex experience. So what do you do now, right? So a lot of people here love custom user models, right? They say, let's just use it, toss everything on there. We're not Instagram, we're not at huge scale. It's fine. You know, that works. Another group, I think it's larger than you might think, just uses user as is. Forget custom user models, use a profile model, that's fine.

Speaker 1: And then there's this third group that does everything from scratch with abstract base user. I would guess it's about a third, a third, a third. And I think we could do a little bit better. So Carlton Gibson is here. He has this great quote. About that, auth is a leaky battery, right? We should push the user model back to being Django's responsibility and address that leak. And this is the argument against custom user models, that they do too much. So they don't focus just on auth, it instead leaks into other areas. He has a fantastic post on the stack report called Evolving Django's auth. user that goes into great detail and provides a lot of opinions. But essentially he put inside three factors that I haven't mentioned yet. One is a complexity tax of custom user models. So it's a battery we should just be provided to users.

Speaker 1: The need to customize auth itself is almost none. What we need to do is add fields, profile fields, for information about the user. So it shouldn't really go on user at all. And you shouldn't get warnings along the way saying in the docs you did it wrong. Ooh, five minutes, okay. Second is a performance tax. So a custom user model quickly becomes a dumping ground, right? You have that pass field on the model. So you say, okay, let's put something here, we're time strapped on a deadline, and then quickly it becomes the place, and then you have 40-50 plus fields on a user model that shouldn't be there. Now on a smaller site, the performance hit, you know, is it so bit so bad? No, you can do things, you can template caching and other tricks, but it's a bad pattern. We shouldn't be doing it in the first place, I would say. And then the third, again, this is I'm paraphrasing from Carlton, so thank you for the thoughts, is

Speaker 1: it doesn't solve the initial problem with user. We wanted to tackle one problem of first and last name, and instead we basically copy it and it's easier than ever to put dump additional fields on there. So this is like where I think we are, right? The docs don't have one approach. We don't have one approach. We have this clouge where everyone's doing something differently. I don't think anyone is 100% happy with it. And meanwhile, we're losing newcomers in perpetuating the idea that Django's hard to learn. User in contrib. auth is 20 years old at this point. Custom user models are over 10 years old at this point. And I think we've learned that there isn't one solution we'd all like. So this helps mitigate a lot of this. This is a fantastic third-party package called Django All Auth. There are other third-party packages, this is one I happen to like, that solves a lot of these problems.

Speaker 1: It has social authentication, it gives you an email-only option, custom forms, toggles, nicely formatted templates. Um and as of Sunday, this Sunday, it now adds passkey signups. You can also do logins. So it's I don't think it's 100% there, but you can start at doing passkeys through Django All Auth, which is fantastic. And this is what I currently do, right? This is when I think about writing a book or making advice to newcomers. This is my approach. It's a kludge of all three, right? Put a custom user model in, but don't use it just in case you need it. Add a user user profile model. And then personally I use Django all auth just to have auth get out of the way from me. Okay, almost done. So what might the future look like? I've listed a lot of complaints, and I hope they're taken with a deep appreciation for the efforts and contributions of Django

Speaker 1: developers up to this point. I know that working on a core battery is hard. Django's pro uh auth is probably the hardest of them all. So I couldn't give this talk and not give an opinion on what we should do. I think we had the solution back in 2012. This is the one Jacob advocated, which is just a simple profile approach. So he has Jacob has a full uh gist laying out and a lot of reasons why, but if we were going to do something, I think this would be the way to do it. I'm a little short on time, so I'll go faster here. There is pro progress being made though. There's already a ticket in 35768 to add information about user profile models to the docs. I got assigned it, so look for that at some point in the future Yeah. This is my final slide. So like any corporate meeting, we need to have some next steps.

Speaker 1: So here's mine. I think we need to update the docs. To go over custom user models, user profile models in a better way. This is already happening. There have been some changes. We should ship with a login template. It's so doable, right? I'd love to have this discussion after. We should have basic signup page. It's so doable. It's it doesn't it doesn't cost anything to add it to start project. And eventually we could add toggles to setting. py to make local defaults a little bit better. We already do lots of things that are not production worthy, but if we just make local better, including with auth, that's a win. I hope this talk has provided context on users' evolution, current status, and ideas for the future. And I would love it if we could continue this conversation.

Speaker 1: There's already a forum thread on Carlton's piece. And I'll just end with, we all know how great Django is. We just need to communicate and market it a little bit better. Do I honestly think we're going to rebuild auth. Probably not. Um can we improve the docs and have more defaults and start project? Yes. So thank you.

Speaker 2: Thank you very much, Will. I think we've got time for one, perhaps two questions.

Speaker 3: Thank you, Will. I have been through tons of arguments about star projects, defaults and so on. Do you think it's something we could put the steering council on and tell them, okay, here is what people have complained about so far and tell us what the vision is? Or do you think it's for other means forward?

Speaker 1: I mean that's sort of the existential of question of Django at the moment, right? Like how do we how do we do it? Uh I'm happy to I I personally would talk with the fellows and like to have maybe have it on the forum thread, but Yeah, the steering council so far hasn't really had to w weigh in on stuff like that, but I'm happy to put together a ticket and be a be have it be approved. I mean again I'm not gonna I think changing auth. user that's That's a big one to basically change the documentation and start project. I don't think should be a problem. So if anyone has concerns, you should raise them Anyone else?

Speaker 2: One more?

Speaker 1: Oh you.

Speaker 4: Can we just add a JSON field to the user object called profile?

Speaker 1: I mean yeah, let's do it. We we should discuss I mean I'm all uh I hadn't I hadn't thought about that one but You tell me, yeah, you're one of the creators. Yeah. I would love to do something, right? Like Yeah. Yes.

Speaker 2: I'm gonna leave it there, but we'll can continue answering questions out in the hallway next. Thank you, Will.

Speaker 1: Thank you, everyone.