This article closes all of them. I replace my small inline role checks with four permission classes, and I add the missing status endpoint.<\/p>\n\n\n\n
And once again, the most interesting part is the bugs. Three of them had the same cause: a name that the framework looks up by string, typed slightly wrong, failing silently.<\/p>\n\n\n\n
Two kinds of permission<\/h2>\n\n\n\n
In DRF, a permission class is a small class that answers one question: is this request allowed? It has two methods you can override:<\/p>\n\n\n\n
- \n
has_permission(request, view)<\/code> is a view-level check. It runs for every request, before anything is loaded from the database. It answers “who are you?”<\/li>\n\n\n\nhas_object_permission(request, view, obj)<\/code> is an object-level check. It runs only after the view has loaded a specific row. It answers “is this thing yours?”<\/li>\n<\/ul>\n\n\n\nBoth return True by default. If any check returns False, DRF stops and returns 403 Forbidden.<\/p>\n\n\n\n
![\"Anatomy](\"https:\/\/rezachegini.com\/wp-content\/uploads\/2026\/11\/job-board-api-part-5-permission-diagram.png\")
<\/figure>\n\n\n\nThe most important detail is in the highlighted box. Object permissions only run when the view calls
get_object()<\/code> orget_queryset()<\/code>. A plain list view never loads one object, sohas_object_permission<\/code> never runs there. Remember that; it explains one of my design choices below.<\/p>\n\n\n\nStep 1: Role permissions<\/h2>\n\n\n\n
All four classes live in a new file,
jobs\/permissions.py<\/code>. The first two only look at who the caller is, so they only overridehas_permission<\/code>.<\/p>\n\n\n\nIsVerifiedCompany<\/h3>\n\n\n\n
class IsVerifiedCompany(BasePermission):\n message = \"Only company accounts can do this.\"\n\n def has_permission(self, request, view):\n user = request.user\n if not (user and user.is_authenticated and user.is_company):\n return False\n company = getattr(user, \"company\", None)\n if company is None:\n return False\n if not company.is_verified:\n self.message = \"Your company account is not verified.\"\n return False\n return True<\/code><\/pre>\n\n\n\n- \n
message<\/code> is the text DRF puts in the 403 response. Without it, users get a generic “You do not have permission to perform this action.”<\/li>\n\n\n\n- The order in the first
if<\/code> matters. An anonymous caller is anAnonymousUser<\/code>, and it has nois_company<\/code> attribute. Checkingis_authenticated<\/code> first uses Python’s short-circuit and, so the attribute is only read for real users. (In practice my views also putIsAuthenticated<\/code> first, see Step 3.)<\/li>\n\n\n\ngetattr(user, \"company\", None)<\/code> turns a missing company row into a clean 403 instead of a crash. The reverse relation raisesRelatedObjectDoesNotExist<\/code>, which is a subclass of bothCompany.DoesNotExist<\/code> andAttributeError<\/code>, sogetattr<\/code> catches it and returnsNone<\/code>.<\/li>\n\n\n\n- For an unverified company, I change
self.message<\/code> to something more useful: “Your company account is not verified.” DRF readsmessage<\/code> from the instance after the check fails, so setting it inside the method works.<\/li>\n<\/ul>\n\n\n\nIsCandidate<\/h3>\n\n\n\n
class IsCandidate(BasePermission):\n message = \"Only candidate accounts can do this.\"\n\n def has_permission(self, request, view):\n user = request.user\n return bool(user and user.is_authenticated and user.is_candidate)<\/code><\/pre>\n\n\n\nOne line.
and<\/code> stops at the first False, so again, anonymous users never reachis_candidate<\/code>. The last expression is already a bool, but I keep thebool()<\/code> to be safe.<\/p>\n\n\n\nStep 2: Ownership permissions<\/h2>\n\n\n\n
The next two classes ask a different question: is this object yours? So they override
has_object_permission<\/code>, and theirhas_permission<\/code> stays at the default True.<\/p>\n\n\n\nIsJobOwner<\/h3>\n\n\n\n
class IsJobOwner(BasePermission):\n message = \"Only the company that posted this job can do this.\"\n\n def has_object_permission(self, request, view, obj):\n user = request.user\n if not (user and user.is_authenticated):\n return False\n company = getattr(user, \"company\", None)\n if company is None:\n return False\n if isinstance(obj, Job):\n return obj.company_id == company.id\n if isinstance(obj, Application):\n return obj.job.company_id == company.id\n return False<\/code><\/pre>\n\n\n\n- \n
- I use this one class on two kinds of object. Editing a job or listing its applicants gives me a
Job<\/code>. Changing an application’s status gives me anApplication<\/code>; then ownership means “the company that owns the job this application belongs to”.<\/li>\n\n\n\n- I chose
isinstance<\/code> over a shorter trick likegetattr(obj, \"job\", obj)<\/code>. That trick would silently treat an unexpected object as a job. I would rather return False for anything I do not understand.<\/li>\n\n\n\njob.company_id<\/code> is the raw foreign-key column stored on the job row. Comparing it withcompany.id<\/code> needs no extra query, unlikejob.company.id<\/code>, which would load the Company row first.<\/li>\n\n\n\n- For a candidate,
company<\/code> isNone<\/code>, so the answer is False and the response is 403.<\/li>\n<\/ul>\n\n\n\nOne design decision here: ownership does not require verification. An unverified company can still edit its own job or change a status; it just cannot post new jobs. Verification is about trust from candidates. Ownership is about access to your own data. Two different questions, two different classes.<\/p>\n\n\n\n
IsApplicationOwner<\/h3>\n\n\n\n
class IsApplicationOwner(BasePermission):\n message = \"You don't have access to this application.\"\n\n def has_object_permission(self, request, view, obj):\n user = request.user\n if not (user and user.is_authenticated):\n return False\n if user.is_candidate:\n profile = getattr(user, \"candidate_profile\", None)\n return bool(profile is not None and obj.candidate_id == profile.id)\n company = getattr(user, \"company\", None)\n if company is not None:\n return obj.job.company_id == company.id\n return False<\/code><\/pre>\n\n\n\nAn application has two people who should be able to read it:<\/p>\n\n\n\n
- \n
- The candidate who wrote it.<\/li>\n\n\n\n
- The company that owns the job.<\/li>\n<\/ol>\n\n\n\n
The method checks the candidate first and returns True early. Then it checks the company. Everyone else gets False.<\/p>\n\n\n\n
I use this class for reading only. A candidate must be able to read their application, but must not be able to change its status. So the status endpoint does not use this class. It uses
IsJobOwner<\/code>. Same object, different action, different rule.<\/p>\n\n\n\nStep 3: A different rule for each action<\/h2>\n\n\n\n
A permission class does nothing until a view uses it. Each of my views needs different rules for different actions, so I override
get_permissions()<\/code> and readself.action<\/code>:<\/p>\n\n\n\nclass JobViewSet(...):\n def get_permissions(self):\n if self.action == \"create\":\n return [IsAuthenticated(), IsVerifiedCompany()]\n if self.action in (\"update\", \"partial_update\", \"destroy\", \"applications\"):\n return [IsAuthenticated(), IsJobOwner()]\n return [IsAuthenticated()]<\/code><\/pre>\n\n\n\n- \n
- DRF calls
get_permissions()<\/code> on every request, and all the returned checks must pass.<\/li>\n\n\n\n- Notice the brackets:
IsVerifiedCompany()<\/code> is an instance of the class, not the class itself.<\/li>\n\n\n\nIsAuthenticated()<\/code> comes first in every branch. That way, a request with no token fails with 401 (“who are you?”) instead of 403 (“I know who you are, and no”).<\/li>\n\n\n\n- “update” is PUT and “partial_update” is PATCH. Both call
get_object()<\/code>, soIsJobOwner<\/code> runs.<\/li>\n\n\n\n- “applications” is my custom action that lists a job’s applicants. Its first line is
self.get_object()<\/code>, which is exactly what makes the object check run on a list-style endpoint. The list itself is then built from that job.<\/li>\n\n\n\nlist<\/code> andretrieve<\/code> fall back to the global rule: any logged-in user can browse jobs. That is on purpose; a job board where nobody can read jobs is not useful.<\/li>\n<\/ul>\n\n\n\nThe application view follows the same pattern:<\/p>\n\n\n\n
class ApplicationViewSet(...):\n def get_permissions(self):\n if self.action == \"create\":\n return [IsAuthenticated(), IsCandidate()]\n if self.action == \"retrieve\":\n return [IsAuthenticated(), IsApplicationOwner()]\n if self.action == \"set_status\":\n return [IsAuthenticated(), IsJobOwner()]\n return [IsAuthenticated()]<\/code><\/pre>\n\n\n\nLook at “set_status”.
self.action<\/code> holds the method name of an action, not its URL. The URL is\/status\/<\/code> (see Step 4), but the action is namedset_status<\/code>. Confusing those two cost me a 404, below.<\/p>\n\n\n\nThe inline checks are gone<\/h2>\n\n\n\n
In Phase 1, my views had small
if<\/code> checks like “if the user is not a company, raise PermissionDenied”. I deleted them all. One example:<\/p>\n\n\n\ndef perform_create(self, serializer):\n serializer.save(company=self.request.user.company)<\/code><\/pre>\n\n\n\nIsVerifiedCompany<\/code> already guarantees a verified company with a real Company row, so this line is safe without a local check.<\/p>\n\n\n\nThere is a nice side effect. Permission classes run before validation. In Phase 1, a company sending an application got a 400, because the serializer complained about a field first. Now it gets a 403: wrong role, and DRF says so before looking at the body.<\/p>\n\n\n\n
Step 4: The status endpoint<\/h2>\n\n\n\n
Now a company can move an application through the hiring pipeline:
PATCH \/api\/applications\/{id}\/status\/<\/code> with a body like{\"status\": \"reviewing\"}<\/code>. The allowed values come from the model: applied, reviewing, interview, rejected, accepted.<\/p>\n\n\n\nA serializer with one field<\/h3>\n\n\n\n
class ApplicationStatusSerializer(serializers.ModelSerializer):\n class Meta:\n model = Application\n fields = [\"status\"]\n extra_kwargs = {\"status\": {\"required\": True}}<\/code><\/pre>\n\n\n\n- \n
- Only one field. The company can change status and nothing else.<\/li>\n\n\n\n
ModelSerializer<\/code> buildsstatus<\/code> as a choice field from the model, so a value like “hired” gets a 400: “\\”hired\\” is not a valid choice.”<\/li>\n\n\n\n- In my main
ApplicationSerializer<\/code>,status<\/code> is read-only, because a candidate must not set it. Having two serializers for the same model, one per action, is normal in DRF.<\/li>\n<\/ul>\n\n\n\nThe extra_kwargs trap<\/h3>\n\n\n\n
That last line,
extra_kwargs = {\"status\": {\"required\": True}}<\/code>, was not in my first version. Without it, PATCH with an empty body{}<\/code> returned 200 and the unchanged application. A silent no-op that looks like success.<\/p>\n\n\n\nThe reason:
ModelSerializer<\/code> makes a field optional when the model field has a default. AndApplication.status<\/code> hasdefault=\"applied\"<\/code> (a new application starts as applied). So “not required” came from the model, not from anything I wrote in the serializer.<\/p>\n\n\n\nextra_kwargs<\/code> changes options on an automatic field without writing the field again by hand, so the choice validation still comes from the model.<\/p>\n\n\n\nOne honest note: my first explanation of this bug was wrong. I thought it was about
partial=True<\/code>. It was not. PATCH being partial is fine; the problem was only that this one field was not required.<\/p>\n\n\n\nThe action<\/h3>\n\n\n\n
@action(detail=True, methods=[\"patch\"], url_path=\"status\")\ndef set_status(self, request, pk=None):\n application = self.get_object()\n serializer = ApplicationStatusSerializer(application, data=request.data)\n serializer.is_valid(raise_exception=True)\n serializer.save()\n return Response(ApplicationSerializer(application).data) # 200<\/code><\/pre>\n\n\n\n- \n
methods=[\"patch\"]<\/code> because one field of an existing object changes. GET or POST returns 405.<\/li>\n\n\n\nurl_path=\"status\"<\/code> sets the URL. Without it, DRF uses the method name, and the URL would be\/set_status\/<\/code>, with an underscore.<\/li>\n\n\n\nself.get_object()<\/code> loads the application and runsIsJobOwner<\/code>.<\/li>\n\n\n\n- Passing the existing object plus data tells the serializer “update this”. Without the object,
save()<\/code> would try to create a new application.<\/li>\n\n\n\n- The response uses the full
ApplicationSerializer<\/code>, so the client sees the whole updated application, not just{\"status\": ...}<\/code>.<\/li>\n<\/ul>\n\n\n\nIn Phase 3, this is exactly where I will put a message on a queue, so a background worker can email the candidate when their status changes. The endpoint does not change; something gets added after
save()<\/code>.<\/p>\n\n\n\nProblems I hit: names that fail silently<\/h2>\n\n\n\n
1. One missing letter:
get_permission<\/code>.<\/p>\n\n\n\nAfter writing the code, I tested it. Globex, an unverified company, posted a job and got 201 Created. My new permission classes were doing nothing at all.<\/p>\n\n\n\n
The cause was one letter. I had named the method
get_permission<\/code>, without the s. DRF only callsget_permissions<\/code>. It never complained, because from DRF’s point of view, I simply had not overridden anything. Every view fell back to the default, which in my settings is justIsAuthenticated<\/code>.<\/p>\n\n\n\nHow did I prove it? With one line in the Django shell:<\/p>\n\n\n\n
'get_permissions' in JobViewSet.__dict__\n# False<\/code><\/pre>\n\n\n\n__dict__<\/code> only holds what is defined directly on a class, not what it inherits. False meant my override did not exist under that name. After renaming, the same check returned True, and Globex started getting 403.<\/p>\n\n\n\n2. Acme was never verified.<\/p>\n\n\n\n
After fix 1, my verified test company Acme got 403 “Your company account is not verified.” The code was right; my test data was wrong. When I created the users in Phase 1, I set
is_verified<\/code> on something else (or only meant to). The database said False.<\/p>\n\n\n\nCompany.objects.filter(name=\"Acme\").update(is_verified=True)<\/code><\/pre>\n\n\n\nI also corrected my Phase 1 notes, which said Acme was verified.<\/p>\n\n\n\n
3. The status URL returned 404.<\/p>\n\n\n\n
My first version had
url_path=\"set-status\"<\/code>. So the real URL was\/set-status\/<\/code>, and my request to\/status\/<\/code> was a 404. I found it by listing the URLs the router actually created:<\/p>\n\n\n\npython manage.py show_urls | grep applications\n# \/api\/applications\/{pk}\/set-status\/\n# \/api\/applications\/{pk}\/status\/ <- after the fix<\/code><\/pre>\n\n\n\n4. The status response was too small.<\/p>\n\n\n\n
The first version returned
ApplicationStatusSerializer(...)<\/code>, so the response was only{\"status\": \"reviewing\"}<\/code>. A client would have to make a second request to see the application. Swapping inApplicationSerializer(application).data<\/code> fixed it.<\/p>\n\n\n\n5. An empty body returned 200.<\/p>\n\n\n\n
This is the
extra_kwargs<\/code> story from Step 4.<\/p>\n\n\n\n6. Command ‘token’ not found in a new terminal.<\/p>\n\n\n\n
My small bash helper for getting tokens only existed in the terminal where I defined it. So I moved it into a file,
helpers.sh<\/code>, and load it in each new shell with:<\/p>\n\n\n\n. .\/helpers.sh<\/code><\/pre>\n\n\n\n.\/runserver.sh # helper: runserver 8000, PYTHONDONTWRITEBYTECODE=1\n\ntoken() { # helper: prints the access token for a user\n name=$1\n curl -s -X POST localhost:8000\/api\/auth\/login\/ -H \"Content-Type: application\/json\" -d \"{\\\"username\\\":\\\"$name\\\",\\\"password\\\":\\\"pass1234\\\"}\" | python3 -c \"import sys, json; print(json.load(sys.stdin).get('access',''))\"\n}<\/code><\/pre>\n\n\n\n.<\/code> is source: it runs the file in the current shell, so the functions stay. Running it withbash<\/code> would define them in a child shell, and they would disappear when it exits.<\/p>\n\n\n\nThe pattern<\/h2>\n\n\n\n
Look at the list of silent bugs so far:<\/p>\n\n\n\n
- \n
get_permission<\/code> instead ofget_permissions<\/code> (this part)<\/li>\n\n\n\nurl_path=\"set-status\"<\/code> instead of “status” (this part)<\/li>\n\n\n\n- “candidateprofile” instead of “candidate_profile” (Phase 1)<\/li>\n\n\n\n
def application<\/code> instead ofdef applications<\/code> (Phase 1)<\/li>\n<\/ul>\n\n\n\nEvery one of them is a name that doesn’t match what the framework expects. None of them raised an error. The code loaded, the server ran, the tests I had at the time passed.<\/p>\n\n\n\n
This is now my working rule for Phase 2: after writing anything the framework calls by name, I check with
__dict__<\/code> that my override is really there, and withshow_urls<\/code> that the URL is really the one I think it is.<\/p>\n\n\n\nDid it work?<\/h2>\n\n\n\n
My test users: Acme (verified company, owns job 1), Globex (unverified company), Initech (unverified company, owns its own job), sam (candidate, wrote application 3), dana (candidate).<\/p>\n\n\n\n
First, I proved that every method is defined where I think it is:<\/p>\n\n\n\n
all('get_permissions' in c.__dict__ for c in (JobViewSet, ApplicationViewSet)) # True\nall('has_object_permission' in c.__dict__ for c in (IsJobOwner, IsApplicationOwner)) # True<\/code><\/pre>\n\n\n\nThen the real requests:<\/p>\n\n\n\n
- \n
- Acme posts a job: 201. Globex posts a job: 403, “Your company account is not verified.” dana posts a job: 403, “Only company accounts can do this.” No token posting a job: 401.<\/li>\n\n\n\n
- Acme applies to a job with a fake job ID: 403, not 400. The permission now runs before validation.<\/li>\n\n\n\n
- Acme edits its own job: 200. Globex edits Acme’s job: 403. Initech edits its own job: 200, because ownership does not need verification.<\/li>\n\n\n\n
- The applicants of job 1: Acme sees 2. Initech and sam get 403.<\/li>\n\n\n\n
- Reading application 3: sam and Acme get 200. dana and Initech get 403.<\/li>\n\n\n\n
- Changing the status: Acme sets it to “reviewing”: 200 with the full application. sam tries to set his own application’s status: 403. dana: 403. Initech, who does not own the job: 403. Globex: 403. No token: 401.<\/li>\n\n\n\n
- Bad status bodies: “hired” gives 400 (not a valid choice).
{}<\/code> and a misspelled key give 400 (“This field is required.”).<\/li>\n\n\n\n- Afterwards, sam reads his application and sees “reviewing”. The company’s change is visible to the candidate it affects.<\/li>\n<\/ul>\n\n\n\n
The goal of Phase 2 has two halves: “wrong user types get 403” and “match scores return correctly”. The first half is done and tested. The second half is the next part.<\/p>\n\n\n\n
What I learned<\/h2>\n\n\n\n
- \n
- Two kinds of permission. “Who are you?” runs on every request. “Is this yours?” only runs when the view loads an object. If the second one never runs, check
get_object()<\/code> before blaming the class.<\/li>\n\n\n\n- Put rules in one place. A permission class is reusable, easy to test, and runs before validation. Inline
if<\/code>s in views were none of those.<\/li>\n\n\n\n- 401 before 403. Put
IsAuthenticated<\/code> first, so a missing token is reported as a missing token.<\/li>\n\n\n\n- Reading and changing are different rights. The candidate can read the application but only the company can change its status, so they use different classes on the same object.<\/li>\n\n\n\n
- Model defaults change serializer behaviour. A field with a default becomes optional, and an empty request can return 200 while doing nothing.<\/li>\n\n\n\n
- The framework never warns you about a wrong name. It just ignores your code. Check that your overrides exist (
__dict__<\/code>) and that your URLs exist (show_urls<\/code>).<\/li>\n<\/ul>\n\n\n\nWhat comes next<\/h2>\n\n\n\n
In the next part, I build the second half of Phase 2: the skill match score. It compares a job’s required skills with a candidate’s skills and returns a score, so candidates can see how well they fit a job, and companies can sort applicants by it. The access rules from this part decide who is allowed to see those scores.<\/p>\n","protected":false},"excerpt":{"rendered":"
Where we are I am a junior DevOps and Cloud engineer looking for my first role in SRE, DevOps or Cloud, and…<\/p>\n","protected":false},"author":2,"featured_media":231,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_rezaops_part":"5","_rezaops_linkedin_url":"https:\/\/www.linkedin.com\/pulse\/building-job-board-api-part-5-who-allowed-do-what-reza-chegini-aigfc\/","footnotes":""},"categories":[10,116],"tags":[8,111,191,118,82,25,112],"series":[117],"class_list":["post-233","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","category-django","tag-devops","tag-django","tag-drf","tag-job-board","tag-permissions","tag-python","tag-rest-api","series-job-board-api"],"jetpack_featured_media_url":"https:\/\/rezachegini.com\/wp-content\/uploads\/2026\/11\/job-board-api-part-5-cover.png","_links":{"self":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=233"}],"version-history":[{"count":1,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/233\/revisions"}],"predecessor-version":[{"id":234,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/233\/revisions\/234"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/media\/231"}],"wp:attachment":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=233"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fseries&post=233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Put rules in one place. A permission class is reusable, easy to test, and runs before validation. Inline
- Afterwards, sam reads his application and sees “reviewing”. The company’s change is visible to the candidate it affects.<\/li>\n<\/ul>\n\n\n\n
- In my main
- Notice the brackets:
- DRF calls
- I chose
- The order in the first