With this new auth method,

it's time to start thinking about permissions, also known as authorization.

Authentication is all about connecting some credentials to the incoming request.

The token you pass in the header maps to the user that has that token.

That authenticates the request if it's from another user.

Authorization though, is about ensuring that the user has permission

to do the action they want to do.

Like CRUD operations or even just accessing the API.

In REST framework, authorization or

permission checks will typically use the authentication information and a couple of

request properties to decide if the incoming request should be authorized.

This happens before your view's methods are ever evaluated.

If the user isn't authorized,

REST framework will return either a 403 Forbidden or a 401 Unauthorized,

depending on whether the user failed authentication or authorization.

Remember when I first started the project?

I set the default permission class to be IsAuthenticated or ReadOnly.

This permission means that you have to provide a real, valid user to perform any

action that involves creating, updating, or deleting data.

Anyone can read the data, though.

What other options do we have?

AllowAny is wide open and allows anyone to do as they please.

IsAuthenticated requires the user to be authenticated,

like by providing a valid token.

Once they're authenticated, they can do anything they want.

IsAdminUser will only allow access to

authenticated users that have been marked as is_staff.

And DjangoModelPermissions ties into Django's standard model permissions.

Authorization will only be granted to authenticated users who have

been assigned to the relevant model permissions.

That's a lot to take in.

So check the teacher's notes for

documentation on all of the different built in permissions classes.

What about setting permissions per view, though?

Let me show you how to protect a single specific view in workspaces.

So I've created a new user.

I want to show you a couple of things about him here.

So this is a test user and

they are active, they're not staff, they're not a super user.

But they do have one permission, which is that they can add a course.

So that's all they can do.

They can just add courses.

They can't add users, groups, anything like that.

They can't log in the admin, nothing.

All they can do is add a course.

So I've saved them and I've already created a token for

them, which I've put here into the readme.

So let's see about handling these permissions.

So I'm gonna hop back over here to views.py and

I need to add an import, so that I'll go here.

From rest_framework import permissions,

and I'm gonna focus on the Django model permissions class.

So like I said, I've already added the user with a single permission, so

I'm gonna take care of that, I'm gonna address that in my CourseViewSet.

So where's CourseViewSet?

Here's CourseViewSet.

All right, so queryset, serializers, OPQ, right?

So permission_classes and its tuple.

So permissions.DjangoModelPermissions.

All right, so what this specifies is that for this view set,

ignore the default permissions and care about Django model permissions.

So make sure that any users who are trying to do things inside this CourseViewSet,

they have the right permissions as far as Django is concerned.

Okay, and since that's a tuple, I could provide more if I wanted to,

they'd fall back, so on and so forth, right.

All right, let's go back over here to postman, postman holds on to your URLs,

as you can see, and also holds on to header and body content.

So I'm gonna make sure and

delete this authorization header, because I don't want that to hang out.

And on the body, I'm gonna make sure and

delete all of my body content, because I want to get rid of all of those.

Okay, so I wanna make sure the get still works.

And Authentication credentials were not provided, so all right, that didn't work.

I got a 401, it's unauthorized, because the Django model permissions,

you have to have the add, the create, the view, whatever.

All right, so, cool.

Don't have that permission, so I can't just do that.

By the way, let me show you real quick the permissions here.

If I come down here to user permissions, let's just filter to course.

So you can see here this change, delete, add?

You have to have change in order to be able to view one.

So I'm not authed, so my unauthenticated user does not have

permission to view one, so all right.

So let's come back over here to Headers, and we'll put in Authorization

and Token, and then my new user's token there and I

will hit send, and yeah, it's the add, the add and the change both let you see them.

I've got the results back, which is cool.

I can create or I can view them, so that's cool.

All right, so now I want to try and create a new course.

So let's go over here and change this to POST again.

Go back to Body, form-data.

Title is gonna be Django Basics.

And my other key here is url

https://teamtreehouse.com/library/django-- basics.

All right, now I have the create, the add permission, right.

So I should be able to do this.

So if I hit send, great, I got back a 201 and django-basics now exists.

All right, so cool, I'm super glad that works.

This user shouldn't be able to delete anything, so let's make sure.

So I'm gonna go to POST, I'm gonna go to delete, and

I wanna try to delete number five, which is the one I just created, right.

And I can get rid of this body data.

That's cool, okay, my header is still in there, my authentication header.

I'm gonna try and delete the one that I just created.

Send, and I don't have permission to perform this action.

So that's great.

I only gave them the add permission.

So they can add new ones,

they can't update, they can't delete, nothing like that.

All they can do is view them or add new ones.

Awesome, if I was using my super user's credentials,

I'd be able to do all of the stuff because they're marked as the super user,

they automatically have all permissions.

So what if I'm faced with a permissions check that isn't built in to REST

framework?

What if I only wanted to apply a permission check to a specific action?

Situations like this come up all the time.

I don't want regular users deleting courses, of course.

I only want super users to have that ability.

How do I handle that?

So first of all, I need to create my own permission class to perform this check.

So I'm gonna do it right up here above the CourseViewSet.

You probably would do this in a permissions.py or

something like that if you were doing this on your own and you had more than one.

So, whatever.

Okay, so class IsSuperUser.

And this will extend the permissions.BasePermission class.

Pretty much all of your permissions are going to extend this one.

And the thing that we override here is has_permission,

and self, request and view.

Those are the arguments that come in.

So this way I can check the = request and make sure it's of a particular type,

I can check the request user, I can do all this kind of stuff.

So if request.method = delete and

request.user.is_superuser, then we're gonna return true,

otherwise we're gonna return false.

I could actually write this a little shorter and

I could just return request.method = delete and

request.user.is_superuser and it checks to make sure those are both true,

but it's fine to make it a little bit longer.

And now I need to apply this class to my CourseViewSet class.

So this is a tuple, let's add in a new one.

And I want to put my special one, IsSuperUser,

above the DjangoModelPermissions one, because I want that one checked first.

So if it is a delete and they aren't a super user,

we just immediately kick it out, we don't ever even go to DjangoModelPermissions.

Cool, right?

I want to change my user here.

And I'm gonna give them the ability to delete a course.

I'm actually gonna give them, they can change a course too, why not?

All right, so I'll save and continue editing so that it just comes right back.

All right, now this user has the ability to delete courses, right?

But they're still not a super user.

So let's see if this works.

So they can delete, hit Send,

they still cannot delete that one because they're not a super user.

If, however, I go to my user,

this is why it's really handy having those tokens saved somewhere.

Come over here to Headers, change that token, hit Send, and it's gone, all right?

And if I was to do a get on courses, I should only see four of them.

How does a super user not have permission to perform that action?

You know what?

I think I need to change my thing here.

So let's do this.

There we go.

Okay, so if it's delete then we come inside here.

That should fix it.

What is that doing?

Let's try that one.

Cool, there we go.

And just to make sure, I will go back over to the other user.

And try to delete one of these.

Let's try to delete number four.

Cool, so the users have to have permission or be a super user.

They can't just delete things just because they want to.

It is possible to check permissions at the object level

with the DjangoObjectPermissions class.

But this requires the use of an object level permissions package

such django-guardian.

Check the teacher's notes section for links to the permissions documentation and

the django-guardian package.

Since I haven't hit my rate limit yet,

I'll see you in the next video to take a look at throttling.