Bird
Raised Fist0
Djangoframework~20 mins

Custom permissions in Django - Practice Problems & Coding Challenges

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Challenge - 5 Problems
🎖️
Custom Permissions Mastery
Get all challenges correct to earn this badge!
Test your skills under time pressure!
component_behavior
intermediate
2:00remaining
What is the output of this custom permission check?
Consider this Django REST Framework custom permission class. What will be the result of has_permission when the user is authenticated but not staff?
Django
from rest_framework.permissions import BasePermission

class IsStaffUser(BasePermission):
    def has_permission(self, request, view):
        return request.user and request.user.is_staff

# Assume request.user.is_authenticated == True and request.user.is_staff == False
class DummyUser:
    is_authenticated = True
    is_staff = False

class DummyRequest:
    user = DummyUser()

permission = IsStaffUser()
result = permission.has_permission(DummyRequest(), None)
ANone
BTrue
CRaises AttributeError
DFalse
Attempts:
2 left
💡 Hint
Think about what the has_permission method returns based on the is_staff attribute.
📝 Syntax
intermediate
2:00remaining
Which option correctly defines a custom permission class allowing only GET requests?
You want to create a custom permission class in Django REST Framework that allows access only if the HTTP method is GET. Which code snippet is syntactically correct and works as intended?
A
class AllowGetOnly(BasePermission):
    def has_permission(self, request, view):
        return request.method == 'GET'
B
class AllowGetOnly(BasePermission):
    def has_permission(self, request, view):
        if request.method = 'GET':
            return True
        return False
C
class AllowGetOnly(BasePermission):
    def has_permission(self, request, view):
        if request.method == 'GET':
            return True
        else:
            return False
D
class AllowGetOnly(BasePermission):
    def has_permission(self, request, view):
        return request.method is 'GET'
Attempts:
2 left
💡 Hint
Check for correct comparison operators and syntax in Python.
🔧 Debug
advanced
2:00remaining
Why does this custom permission always deny access?
This custom permission class is intended to allow access only to users with username 'admin'. Why does it always deny access?
Django
from rest_framework.permissions import BasePermission

class IsAdminUser(BasePermission):
    def has_permission(self, request, view):
        if request.user.username == 'admin':
            return True
        else:
            return False

# But in testing, even user 'admin' is denied.
AThe method should be named has_object_permission instead
Brequest.user is AnonymousUser without username attribute
CThe permission class is missing the 'SAFE_METHODS' check
DThe user model does not have a username field
Attempts:
2 left
💡 Hint
Think about what request.user might be if the user is not authenticated.
state_output
advanced
2:00remaining
What is the value of allowed after running this permission check?
Given this custom permission and a request with method POST and user.is_authenticated True, what is the value of allowed?
Django
from rest_framework.permissions import BasePermission

class IsAuthenticatedAndPost(BasePermission):
    def has_permission(self, request, view):
        return request.user.is_authenticated and request.method == 'POST'

class DummyUser:
    is_authenticated = True

class DummyRequest:
    user = DummyUser()
    method = 'POST'

permission = IsAuthenticatedAndPost()
allowed = permission.has_permission(DummyRequest(), None)
AFalse
BRaises AttributeError
CTrue
DNone
Attempts:
2 left
💡 Hint
Check both conditions in the return statement carefully.
🧠 Conceptual
expert
2:00remaining
Which option best describes the purpose of custom permissions in Django REST Framework?
Select the option that most accurately explains why and when you would create custom permission classes in Django REST Framework.
ATo define specific rules controlling access to views beyond built-in permissions, such as user roles or request methods
BTo replace authentication mechanisms like token or session authentication
CTo handle database migrations and schema changes
DTo automatically generate API documentation for endpoints
Attempts:
2 left
💡 Hint
Think about what permissions control in a web API.

Practice

(1/5)
1. What is the main purpose of creating a custom permission in Django?
easy
A. To control user access based on specific rules you define
B. To change the database schema automatically
C. To speed up the Django server response time
D. To create new database tables for users

Solution

  1. Step 1: Understand what permissions do in Django

    Permissions control what users can or cannot do in the app.
  2. Step 2: Identify the role of custom permissions

    Custom permissions let you define your own rules for user access beyond default ones.
  3. Final Answer:

    To control user access based on specific rules you define -> Option A
  4. Quick Check:

    Custom permissions = control user access [OK]
Hint: Custom permissions control access rules you create [OK]
Common Mistakes:
  • Thinking permissions change database structure
  • Confusing permissions with performance settings
  • Believing permissions create new tables
2. Which method must you override when creating a custom permission class in Django REST Framework?
easy
A. save
B. get_queryset
C. has_permission
D. dispatch

Solution

  1. Step 1: Recall the BasePermission class methods

    The main method to check access is has_permission.
  2. Step 2: Confirm which method controls permission checks

    has_permission returns True or False to allow or deny access.
  3. Final Answer:

    has_permission -> Option C
  4. Quick Check:

    Permission check method = has_permission [OK]
Hint: Override has_permission to define access rules [OK]
Common Mistakes:
  • Using get_queryset which filters data, not permissions
  • Confusing save method with permission checks
  • Using dispatch which is for request handling
3. Given this custom permission class, what will be the result if a user is not authenticated?
from rest_framework.permissions import BasePermission

class IsAuthenticatedCustom(BasePermission):
    def has_permission(self, request, view):
        return request.user and request.user.is_authenticated
medium
A. Code raises an error due to missing return
B. Access is denied because user is not authenticated
C. Access is granted regardless of authentication
D. Access is granted only if user is staff

Solution

  1. Step 1: Analyze the has_permission method logic

    It returns True only if request.user exists and is authenticated.
  2. Step 2: Consider the case when user is not authenticated

    Then request.user.is_authenticated is False, so method returns False denying access.
  3. Final Answer:

    Access is denied because user is not authenticated -> Option B
  4. Quick Check:

    Unauthenticated user = access denied [OK]
Hint: Check if user.is_authenticated is True to allow access [OK]
Common Mistakes:
  • Assuming access is granted without authentication
  • Thinking code raises error due to return statement
  • Confusing staff status with authentication
4. Identify the error in this custom permission class:
from rest_framework.permissions import BasePermission

class IsOwnerPermission(BasePermission):
    def has_permission(self, request, view):
        return request.user == view.get_object().owner
medium
A. Missing import for request module
B. No return statement in has_permission
C. Incorrect comparison operator used
D. Using has_permission instead of has_object_permission for object check

Solution

  1. Step 1: Understand permission methods roles

    has_permission checks general access; has_object_permission checks per object.
  2. Step 2: Identify misuse of has_permission for object ownership

    Comparing user to object owner requires has_object_permission, not has_permission.
  3. Final Answer:

    Using has_permission instead of has_object_permission for object check -> Option D
  4. Quick Check:

    Object checks need has_object_permission [OK]
Hint: Use has_object_permission for per-object access checks [OK]
Common Mistakes:
  • Confusing has_permission with has_object_permission
  • Assuming import errors cause this issue
  • Thinking comparison operator is wrong
5. You want to create a custom permission that allows access only if the user is authenticated and the HTTP method is safe (GET, HEAD, OPTIONS). Which is the correct implementation?
hard
A. class SafeAndAuthenticated(BasePermission): def has_permission(self, request, view): return request.user.is_authenticated and request.method in ['GET', 'HEAD', 'OPTIONS']
B. class SafeAndAuthenticated(BasePermission): def has_permission(self, request, view): return request.user.is_authenticated or request.method in ['GET', 'HEAD', 'OPTIONS']
C. class SafeAndAuthenticated(BasePermission): def has_permission(self, request, view): return not request.user.is_authenticated and request.method in ['GET', 'HEAD', 'OPTIONS']
D. class SafeAndAuthenticated(BasePermission): def has_permission(self, request, view): return request.user.is_authenticated and request.method not in ['GET', 'HEAD', 'OPTIONS']

Solution

  1. Step 1: Understand the requirement

    User must be authenticated AND method must be safe (GET, HEAD, OPTIONS).
  2. Step 2: Analyze each option's logic

    class SafeAndAuthenticated(BasePermission): def has_permission(self, request, view): return request.user.is_authenticated and request.method in ['GET', 'HEAD', 'OPTIONS'] uses AND with correct method list; others use OR, NOT, or wrong method checks.
  3. Final Answer:

    class SafeAndAuthenticated(BasePermission): def has_permission(self, request, view): return request.user.is_authenticated and request.method in ['GET', 'HEAD', 'OPTIONS'] -> Option A
  4. Quick Check:

    Use AND for combined conditions [OK]
Hint: Use AND to combine authentication and method checks [OK]
Common Mistakes:
  • Using OR instead of AND allowing wrong access
  • Checking for methods incorrectly with NOT
  • Allowing unauthenticated users by mistake