Finally Understand Authentication in Django REST Framework by William S. Vincent

Speaker 1: Okay, we have display now. So once again our speaker is Will Vincent. He'll be talking about figuring out authentication in Django REST Framework. Let's give him a round of applause.

Speaker 2: Thank you. I'm honored to be here today. It's my first DjangoCon and we're gonna talk about Authentication, which for me personally, and I think for many people is the hardest part about switching from a traditional Django web app to an API. And before I start, I want to talk about remind us where we all are. I asked beforehand, and many of you already use Django REST Framework. But if you remember when you started off as a web developer, You know what did that look like? You had an idea of, you know, I want to build a website. So how do you do that, right? You think you go online, you ask a friend, you find out about HTML. So there's your first language. You build a page, doesn't look good, but you figure it out. Then you say, I want color, I want to change the shapes.

Speaker 2: Another language, CSS. Figure that out, now you're on two languages and you sort of have a website. But then you want some interactivity, right? So then you say JavaScript. So now it's a programming language. So your third one. Go online, find some jQuery code, slap it on. It works. I don't understand why, but you have the widget. Right? And there's a point to this. And then you say I want to build an interactive database driven website. Or really you say, I want to build Twitter or Instagram or some clone. So then you ask someone, a developer, and they say we need to learn about databases And you could do it in JavaScript, um, but Python's really awesome, and so is Django. So now you're on your fourth language. So now you're on Python. And then you have to learn Django. And then you have to learn web development. And you stumble through and you get something up, fingers crossed, it just works.

Speaker 2: And traditional Django authentication really is just taken care of care of for you. You don't have to understand it. But you're not done, right? Someone comes to you and says, hey, we have a front-end person, we need an API. So now it's what's an API? How do I build an API with Django? Django REST Framework. Again you stumble through, you look at the official docs, and this is where I think a lot of people go, you know, oh god Because there's four built-in ways to do user authentication. And there's over a dozen third-party packages. There's JWTs, there's OAuth. And because you've a lot of people have kind of you learned what they needed to know, they hit this point and they realize they don't know how HTTP works or the web works. Because with APIs, it gets real, really fast. So in this talk, we're going to cover a lot of ground.

Speaker 2: We're going to start with the fundamentals and we're going to build up. We're going to cover all the built-in Django REST framework authentication options. We're going to talk about JWTs. I've got full complete working code examples in all the in a repo I'll link to at the end. And I'm happy to take questions. You can interrupt me as I go. This stuff is confusing, and I think it's good to remember what we all many of us in the room already know, but many people don't. So this is me. I'm a freelance software developer out of Boston. I learned programming a little bit later in life when I was 32. I'm 38 now. Okay, don't do that screen. And uh I've worked at a number of early stage startups, most notably

Speaker 2: Quizlet, which is okay, which is an ed tech company in San Francisco. All right. I've also loved to teach. I've taught at the undergraduate level. And I firmly believe because I came to coding a little bit later in life that the challenge is primarily that it's poorly explained. A lot of people learned coding when they were younger and they've just forgotten how complicated it all is. So a lot of what I do is I really like working with beginners. and trying to demystify all this stuff because it's not sending people to the moon, right? But it still gets really complicated building CRUD with auth again and again and again. All right. Um I've also written two soon to be three books on Django.

Speaker 2: Um started off as my own notes. First one, uh Django for Beginners. That's free really annoying. Django for beginners. You build five apps starting with the low world, REST APIs with Django. That's where a lot of the material for this talk comes from. And then by the end of the year I'll have a third book, Django for Professionals. Again, I'm always mystified at how people learn Django because I feel like there's a wide lack of good material. So a lot of these are my own internal notes as I was learning and then I put them to paper. I also have a personal website with a whole bunch of articles on Django. This is largely so I don't forget what I've learned. Um right, because you're frustrated with something, you figure it out, and then you kind of forget it.

Speaker 2: So I've been writing for a couple years now in Django, and it's only the last year that Um I get real traffic. Um so now when I Google stuff I often see my own post, which is um frustrating and flattering at the same time because I wished, you know, I ex went that further step for whatever I'm stuck on. Um but the point being like all of you should write about what you're learning. Um when you're learning is the best time to teach it. Um and it saves you time personally, right? I mean it's easier to put online rather than have a notebook full of ideas. And finally, I have a GitHub repo with uh Django X, the Django starter project, DRFX, starter project. Again, just basic stuff that I didn't see really covered anywhere with uh

Speaker 2: Custom user models, authentication, all the good stuff. All right, so we're gonna start, we'll start here. API. Application programming interface. And this is just rules for how one computer talks to another. Many of us know this, but many beginners hear the term tossed around. I think it's important to talk about acronyms. And specifically we're talking about web APIs. So that can be internal or external. Internal would be if you're Instagram, you have one database that wants to talk to your own iOS app, Android app, you know, uh web app. But it can also be external. So you can also we can all go sign up for a developer key and consume the in Instagram API. So it's all the same database and with permissions and authorizations you can access it. So we're going to talk about the authorizations part.

Speaker 2: Excuse me, authentication pardon. And we're talking about RESTful APIs. So Graph uh QL is another type of web API that's really interesting we can talk about later. But REST APIs is the dominant pattern on the web today, uh been around since about 2000. And there are you know entire books on what is RESTful, and I don't want to get into that debate, but I think we can all agree these are four of the major points A big one being that it's stateless. So each back and forth each back and forth is uh self-contained. So that helps with consistency, but that means we have to manage state. And specifically, just because you authorize someone, how do you know that they're still authorized? We're going to get into that. Support common HTTP methods.

Speaker 2: We're going to talk about those. Has URL endpoints. So a URL. Instead of returning a web page with HTML, CSS, JavaScript, we'll give us a resource, typically data, in JSON or XML format. All right. And Django REST Framework uh is worth mentioning is not part of Django. It's a third-party package. It's the most popular by far now. It is deliberately very similar to Django itself, so if you know Django, uh you can get up and running uh pretty quickly. Um And it's the default choice. I think these days almost everyone is using it. There are some other ones, there's some new cool ones, but if you're using an API with Django, you're building with Django REST framework. And again, the value is that you can take your one database and you can do your React front end, your View front

Speaker 2: end, all the front ends you want, go crazy. All right. Who knows what that is? Yes, internet cable. So this is, you know, I could pick a bunch of different images. This is the internet, right? These are submarine cables. Um It can be underground cables, telephone poles, satellites, cell phones, but it literally is just a collection of tubes, as uh Senator Ted Stevens said. I mean it really is, right? It's one big network. And I think if you asked a lay person, you know, what is the difference between the internet and the worldwide web, they wouldn't be able to tell you the difference. So it's I find it's important to remember that. start and build up. Um you know notably it was only came around around the nineteen sixties um in the US with military, um, government

Speaker 2: academics, but it was closed systems. It was private networks that could only talk to one another. And you know, over time it was the idea came, wouldn't it be nice if a computer in the United States could talk to a computer in Africa or China? That'd be nice, right? Anyone know who this guy is? Right, Sir Tim Berners-Lee. So he had the same idea in the early 90s. He used a scientist working at CERN, the largest particle uh accelerator laboratory in the world at the time. And so big experiments, lots of data being sent to scientists all over the world. And he said, well, it'd be nice if I could share this more easily with other academics. And what he did is he said there was an existing hypertext

Speaker 2: standard out there. So documents with links that connect to other documents. And he took that and he put it on top of the internet, which already had TCP, IP, DNS. And so he invented a new protocol, HTTP. Hypertext transfer protocol. So this is the part that the journey I mentioned in the beginning, a lot of newcomers really don't dive into HTTP because stuff just works. It's just handled for you in web frameworks. But with an API, you need to know it. And again, there's I think it's important to note there's other protocols. There's SMTP for email, there's FTP for file transfer. So again, you know, web versus internet, the difference is the web uses HTTP. And web APIs literally sit on top of HTTP, so we need to know it.

Speaker 2: So what how does HTTP work? It's a request-response cycle between the client, which could be my computer and the server. which would be another computer in a data center somewhere. Back and forth, back and forth, back and forth. We're going to get into that more and more. But you do things like get the home page, here it is, post this information to my blog. Here it is. Authenticate or authorize this user. Okay, now you're authorized. And quickly, these are the HTTP uh HTTP verbs. that we all know and love that correspond roughly to CRUD. So if if that's annoying, I can try to fix that, but I can also just talk through it. So common HTTP verbs, these are the main ones. Create

Speaker 2: corresponds to post, read to get, update to put or patch. I won't get into the differences, and delete isn't delete And status codes, right? Again, when you're starting out learning, these are the things you sometimes see and go, ugh, right? Usually you see a 404, which you're on the wrong page, or 500, the server. Really screwed up. But there's also 200s around success, 300s for redirection. These only really become important when you're building the API yourself. So we'll talk a little bit about those. All right, so this is just we're gonna start with a web page and then we're gonna move to an API. So this is example. com, just as it is. So I typed into my computer. My uh

Speaker 2: my web browser, there's actually a lot that happens, but big picture. I hit return, a get request is sent to the server and sends back not this beautiful page. But this, right? View source, all the HTML. So it's just sending us data, but for a web page, it's HTML, CSS, JavaScript. Alright, now we're gonna get into HTTP. So all of HTTP, so what is in those messages You know, when I was learning this stuff a while ago, I couldn't find good explanations of it. It just seemed mysterious, long gobbledygook, if I could even find what it looked like. But it's not that bad, right? There's three parts. Request has a start line, uh

Speaker 2: header, and it could have a body. And a response has a status line, header, and a body. We're gonna go into all three of those. And actually a quick question for you guys before we get in. Do I have to have a header on a resp on a request? Okay, we'll vote on it. Who says no? Who says one header? And who says more than one header? Okay. So the answer is for a I'll get to the answer in the next slide. Um so this is the simplest uh uh start line you can do where we have our http method.

Speaker 2: So this is a get. We say the domain we want to go to. This is our URL endpoint, so example. com, and you have to specify the HTTP We're generally on 1. 1, 2 exists and is really cool, but we won't talk about today. But this is as I feel like this is karma for something I did, right? But um this is as simple as it gets. We're saying get this URL using HTTP. This is what the raw uh status uh start line would look like. And this is the response that you get back. So the server sends back to us in the status line, not the start line. Okay, you're using this version of HTTP, and here's your status code, it's all good. And below it we'll have information we'll get into.

Speaker 2: Alright, headers. So this is the the trick question. This is the with what 1. 1, you have to have a host, but that's it. With a post you need more information, you need a content length or transfer encoding. But for a GET request, all you need is a host. And I highlight this because I think for me, headers is just a whole bunch of gobblygook that I try to ignore. It's really generated by the server and Until I need something, it's easy to ignore it, but it's really, really important, right? This is like the metadata in the head of our HTML documents. You can't see it on the page. but it's really important the client and the server both need it. And as we'll see, this is where the authentication happens. So

Speaker 2: now we have two lines. We have our start line, we have our header and the request being sent to the server. Go get this. And then here's the response with the header from the server. Now there probably are more headers than this. The important thing is that this is the type of information that's in there, things that are helpful, the date. telling us that it's HTML, that's UTF-8 , the content length, lots of additional information can be included. This is as simple as I can make it Okay, now we're on the body. So now body is optional, right? If you're doing a request, you're not sending anything, you're just saying, give me the page back. If you're doing a post, you would send something, and that would be either there'd be a space and be on the other line.

Speaker 2: And this is what the full HTTP response would look like from the server. So again, we have our um status line up top in blue, we have our headers, and then this is just the HTML getting back to us. So it's really not magic. I think it can seem like magic, but it's just three parts and back and forth, back and forth. All right, and this is high level again, this is what you're asking for, this is what you get back. We'll get more into that. All right, so what's a REST API endpoint? This is so now we're talking about not a web page, but an API where we're going to get data. The key difference is it's going to send us generally a resource, which will often be in JSON

Speaker 2: format. And this will often be located on a subdomain. So you know, github. com is where you go for GitHub, api. github. com. is where the API is. Twitter has the same subdomain API, twitter. com. It's just URLs, but different rules. Not sure why this is here now, but uh this is the repo with the examples uh for the code you can look at later. Oh that's right, because I have an example, there's an example in there that um I'm gonna talk through, but don't don't go load it yet. So in this repo I have a very basic Django Rest framework package where I have a users

Speaker 2: and users URL that just lists all users. So again, I'm trying to keep this as simple as I can to start. We're using curl here, which you've never if you've never used it before is a great command line tool to make requests. And this is kind of a greatest hits version of curl. Notice we're not putting the get in there. It assumes a get. Put the get in as well. And it just gives us back what we really want. It doesn't have all the headers and everything else. It's just the greatest hits version of our HTTP. If you add the dash V for Verbose tag, now you're starting to see the full information, right? So up top you have our full request. with our get, our host, and then our response.

Speaker 2: Again, so we have the uh status line, we have our headers, and then we have the inf information down here. This is what it looks like raw HTTP, but Django REST framework gives us a really nice visual representation of it thanks to Tom Christie, Carlton Gibson, and others. And it tells us the same information. So we have our GET request, we have our URL, and look, it's the same information. We have our there's our status line, our status information, our headers. and our uh the return, the body. So again, it's possible if you're just starting out, you just see this. You don't really understand how it works, you can use curl, you can go dive in deeper, and then I think the

Speaker 2: responses that you see look uh make a lot more sense. All right, so now we're talking about authentication, which I love this XKCD about authentication. What is it? Authentication is saying who you are. Authorization is what can you do? So we need a way, again, HTTP is stateless, so it doesn't have any memory. How do you know that I've logged in, that I am who I say I am? All right.

Speaker 2: What do you guys think I should do? This is annoying, right? I'm just gonna talk through it. We're just gonna go through it. This is the most basic way it can be. So this is a two back and forth. Have our get request, give me this resource. We'll just assume the homepage is locked down for some reason. So notice the server It sends us back not a 200, a 401 unauthorized, which says no. But it tells us in the header, thank you headers. W authenticate using in this case basic, we'll get into the types, but it's telling us you need to use basic authentication to uh Validate who you are. So we say no problem, let me send that again. I'm gonna use the authorized authorization header. You know, a lot of headers. This is one we need. And I'm including

Speaker 2: This long string, we'll talk about how it's generated, that proves who I am. The server says, oh, now you've got that string in the format I asked, I know who you are. This is this is basically what the talk is. This is how authentication works. Broadly speaking. Alright, so now Django S framework. Four built-in types. Why? Right? Like why? Do what do we really care? And we we do, but we're going to break down all four of them. So there's basic authentication, session authentication, token authentication, and remote user authentication. I'm curious how many people have used remote user authentication in this room? Okay, couple. All right, awesome. All right, so again, this is the flow. We're gonna get familiar with it.

Speaker 2: So basic authentication, the most basic type there is, send me the resource. Server says, who are you? Identify yourself. the 401 uh status code and the authenticate header. And with basic, we say, here's my username and password. I'll just put it in clear text, base 64 encode it, and I'll have it in the header. And we'll pass it back and forth. The server says, oh, that looks good. We're good to go. So now in every subsequent request, In the header, we're going to include the username and password. Now that's nice and easy, uh simple to understand. It is We'll get to yep, so full thing back and forth, authenticate, here's who I am, here's base64 and code. So we could decode that. I think it's

Speaker 2: WSV is the username and test pass 123 or something, but you could just plug that in and decode it. There's nothing mysterious about that. Okay, got ahead of myself. And then how do you add it to an existing uh how do you add authentication? It's really easy with Rest framework. We go down to our default authentication classes. Boom, right there. That's really all you need. Alright, so pros and cons. The pros is really simple. If you're just starting out, if you're prototyping. It's fine. Like just you need to use something. Don't overcomplicate things unnecessarily. I'm a big believer in that. The cons are it's sent on every uh request so it's a little bit inefficient. Um passing the credentials in clear text

Speaker 2: that's not good but for testing that's fine. Um and you should always use you know HTTPS, you should anyways. But again, it's fine for prototyping. Don't get complicated if you don't have to. Alright, cookies and sessions. Like I still think cookies have a hilarious name because this is what I think of when I think of cookies still. Really, we know it's just a string of information stored on your computer, but um Cookies and sessions are important because this is how Django works. I think a lot of people who went on that progression I spoke of in the uh in the beginning They never really dive into what's a cookie in a session. So we're going to talk about that briefly. So

Speaker 2: similar flow, client says, hey. I want this resource. Who are you? I'll log in with credentials. Now, notably what it'll do is it'll create two things. The server will create a session object. And an ID. And it'll only send the ID back to the client. So the client says, okay, here's the ID ID. In every uh request in the header, authenticate, it will pass the ID. So the ID is then used on the server to look up the full session object. And we do that in every request where we need to be authenticated. Again, it's a one-line one-line change. Thank you, Django Rest Framework. And pros

Speaker 2: and cons, my opinion on it. Pros are that it is secure. It's what Django uses, it works quite well. You only have to validate once, then you use the session ID to pass back and forth. You're not putting the username and password in every single request. But there are some challenges. It's not good for multiple front ends. Because the session uh, you know, how do you have if I'm logged in on my website and on my iOS app You can only have one session per user. How do you handle that? Also on large apps you can have problems of scale where you have multiple servers. Things are changing. How do you keep the session object between multiple servers up to date? That can be a challenge. But basically, you know, cookie session, that's the default way that traditional websites work.

Speaker 2: It's quite secure. Django uses it. But there is another thing called tokens. So token authentication is similar pattern. Who are you? Identify yourself. Here's my credentials. Okay, great. I'm creating a signed token. Now the token has all the information on it, but uh it is uh excuse me, is is signed so it can't be tampered with. Um and then we check the token on every request. So let me explain a little bit more. So again, the important thing here, and to me this was eye-opening, and I think if this is your first time seeing this, you know, all that's happening is you're requesting the web page The server is saying, okay, 401 unauthorized, so not a 403, you can't do it, but you need to authenticate in.

Speaker 2: And it's telling us now, I want a token. Not basic, but I want a token. And then you send a long string your token with each request back and forth. Oops. How do you add it? Okay, it's a one-liner in the bottom. And installed apps you have to add auth token. This is so nice and straightforward, I think. And tokens, right? So tokens are easy to scale because you're it's being passed back and forth. You don't have to worry about um well let me rephrase that. You only validate the user once. So as soon as you send your credentials, get the token, the token says has all the information on there that you need.

Speaker 2: And you can have multiple sessions. So you can have multiple tokens Or you can pass the token separately from your computer, from your um from your phone. There's not a session that you have to manage as well. I didn't explain that very well, but I'll try again. What are some cons? The base, you know, token authentication, it works, but the tokens never expire. You can fix it, but the uh you know the implementation here they don't expire. You might have issues over refreshing them. Because if I steal your token, I steal you. Uh so that's a problem. And then remote user authentication. So this is rarely used, largely for internet sites. I'd love to talk to some of you who've implemented it. We're largely not going to cover it because it's about

Speaker 2: web stuff, but it's there for you if you want it. And actually I would love to learn more about it. It's a little bit mysterious to me. All right, so here's my quick takeaway. Um, when to use what? So basic authentication, it is insecure, good for testing, just get up and going, don't complicate things. Sessions is fine if maybe you're just building a website, you have a REST framework backend and you have a React front end and that's it. You can use sessions. It powers the visualizer, the GUI for Django Rest Framework. Tokens is probably the default that you want. It's pretty secure. You can do multiple front ends. And then remote user authentication. You know, if you're asking me, you probably shouldn't be using

Speaker 2: All right, JavaScript web tokens. So this is an update on traditional tokens. And I'm gonna quickly look at my slides here. And there's generally three parts, right? So we have in red we have a header, we have a payload, and we have a verify signature. Uh we're gonna break down each of those, but basically the header specifies as the algorithm. We can use lots of different types of algorithms to um to vote to uh to sign it. The payload has all in for all our information. And this is just um this is not in uh this is not encrypted by default. We'll see that in a second, though you can encrypt it.

Speaker 2: And the third part at the bottom, there's a verify signature which is generated from the header and the payload. So again, if someone gets your JavaScript web token, they can impersonate you. So be careful with it. Um to me I think this is interesting. Like this is literally what that long string, that first one, it just says this. And you can go prove that this is the case. We're specifying an algorithm and the type JavaScript web token. Again, you know, so it's not magic. This is the payload in this case. We can put all sorts of information here. We could say, you know, last time we logged in, um, email, whatever you want about the user. In this case, this is just my name and the message, hi DjangoCon.

Speaker 2: And then this is the verify signature which is generated for us. So sign signature means no one can tamper with it, but they can still read it. And again, this is a great site, jwt. io, where you can plug in any JavaScript web token. I and you can see, if you put it on the left, you can see it on the right. You can also change it on the right and see it change on the left So again, there's no magic here. JavaScript Web Token lets us cram in a lot more information in the JSON format. All right, so how do we use them? There's two dominant packages, um Django, REST Framework, JWT. and Django Rest framework simple JWT. Simple JWT is a little more up to date, so we're going to use that one today.

Speaker 2: But if you have an existing API, you just add the package. And down here under default authentication packages, you add it in. That's it. Now you switched over to JWTs. That's pretty nice. There's more I could say about it, but that's a quick high level, what are they? Why would you use them? Again, it's amazing how simple it is to add it to your project, and you can customize it a million ways to the sun if you want. So, should you, right? Pros and cons. Um, you can store more data. It's signed, which is nice. You can encrypt it, which is a good idea. You can do things like set it to expire, which is important for security. So you can say this is only good for five minutes or whatever time frame

Speaker 2: you want. Again, because if someone captures your token, they are you. Um the cons are its size can grow large if you don't manage it properly. It's being sent on every request and response. Um so That can be performance hit. And the setup is more complicated. So my rule of thumb would be I get asked, should I use them? If you have a reason to use them, use them, but don't just use it because it's the cool tech. Um don't complicate things. Um now we are how are we doing on timing by the way? 10 minutes. Okay, awesome. So this is a for those of you who are new to REST APIs, this is a you just get up and go um starter project with Django REST Framework.

Speaker 2: recommend checking out. And now I want to quickly step through how I would do a new project from scratch because I find this helpful. And again, this is all documented in the repo, so don't need to take notes or anything. Alright, so I like pipenv, you don't have to use it, you can use pip, but you install Django, start up your shell, start a new project. We're just going to create a simple users app here. Happy to take questions on this. And you know you're in the virtual environment because you have parentheses around uh the name. All right, first thing, custom user model. I'm a big advocate of using explaining to beginners they need to use custom user models because I think if I could change something about Django, this would be one of the big things is that it's really a gotcha.

Speaker 2: You dive in, you're using the user model, maybe you build something up, and then you want to change it, and someone says, oh, you didn't know about custom user models, it's in the documentation, you know, you're effed. Uh It's kind of unfair, right? And I understand you want to keep it simple, but you can really simply implement a custom user model up front. This is how I like to do it. So you add Users app, down here we say okay, we're gonna extend our we're gonna have a new model, custom user. And this is all you have to do. You don't even have to put anything it. You can just put pass. I'm simply extending the built-in I'm using abstract user here. You could also do abstract base user. Don't use it until you need to. Be my rule of thumb. Abstract user just lets us easily extend it.

Speaker 2: Abstract base user, you're rewriting a lot of Django. If you need to do it, otherwise don't. But this is all you need, right? It's it's just this. Boom, user's app, change your auth user model. Here it is. I always try to explain this more to beginners because I think it's not that bad and it's important to have. All right, and then we go through. Uh we are in our admin. We want to be able to see the user's app. This is pretty straightforward to this crowd. Got to migrate our new app, or excuse me, make the migrations. We migrate it, create a super user. So now, you know, this is also the gotcha. Don't migrate until you have your new custom user model. That's important if you migrate up front. The admin and all the

Speaker 2: other parts of Django are gonna be upset with you. You have to wait on that migrate. That's a gotcha. And then we run the server. So that's it. Now you have custom user model. Now it's time for Django REST framework. We can just install it again with pipenv. How do we add it? You know, uh We just add it as a nice third-party app. This is optional. This actually maybe I'd put third party above local. Doesn't matter as long as it's the bottom of installed apps. We need rest underscore framework. Because we're going to use tokens, we also add the auth token, but if we were using basic or sessions, we would not uh have to include that. So now there's there's a gotcha here. Um in the settings at the bottom, by default REST framework gives you um basic and session authentication uh implicitly, so you can explicitly set it.

Speaker 2: Um in this case we're using tokens. So why do you have session and token? It's because sessions is if you want to use the web interface You need to have sessions as well. So generally speaking you're always gonna have session and then you're gonna have token or JWT. I lost hours of my life figuring that out. You need both. Sessions is to power the web uh interface for Django Rest framework. Maybe I'm the only one who made that mistake. All right, now we migrate it. Now, again, how do we do our our endpoints? So we could roll them our own. For login and logout, I like using Django Rest auth. That's just a personal preference. Again, we add rest auth here. I'm going to go a little bit faster because there's notes

Speaker 2: in the repo. I add the URL pattern for it, just rest auth, include it, nice and straightforward. And it gives me the login and logout endpoints that we can now use. So very little code. You know, I could write my own, but this is a a package used by a number of people, and until I need to rewrite it, why do I rewrite it? All right, last thing, we need sign up. So Django all auth is how I like to do it. I think most people in this room use that. Add a whole bunch of things here. I've got to add sites, account, registration. Could talk more about that, but we don't have time. This is an important one. You have to add specify your email backend, because by default it will want to send something when someone uh logs in. or excuse me

Speaker 2: signs up. In this case we're just using console. It's just going to put it into our command line. You could also have that so it'll uh change it so it will send an email through an email server. service. And you need to add the site ID because it uses the site's framework in Django. Add just here at the bottom, rest auth registration. That's all you need. migrate run server and now we have our signup endpoint. So you know I went through that quickly. If you think about what we just did there, we built a Django project, we built an API, we have our users app, we have login, logout, and sign up, and it's A couple dozen line of lines of code, that's pretty awesome. And um when I teach to beginners, I really like to use that approach and try to make it as simple as possible.

Speaker 2: Okay, we got through this. Um I have source code up there, uh DjangoCon 2008 Restof. Again, I've got a working uh basic concession implementation you can use and look at. Um I have token one and I have a working uh JWT. These slides are also up as well and my information is on my website. Please feel free to email me with any Any questions? Thank you, guys.