Custom permissions in Django - Performance & Optimization

Performance: Custom permissions

MEDIUM IMPACT

Custom permissions affect server response time and API interaction speed, impacting how quickly permission checks complete before rendering content.

Checking user permissions for API access

Django

class EfficientPermission(BasePermission):
    def has_permission(self, request, view):
        # Use cached user roles or prefetch related data
        user_roles = getattr(request.user, '_cached_roles', None)
        if user_roles is None:
            user_roles = list(UserRole.objects.filter(user=request.user))
            request.user._cached_roles = user_roles
        return any(role.name == 'admin' for role in user_roles)

Caches database results to avoid repeated queries, reducing server processing time.

📈 Performance GainReduces permission check time by up to 80%, improving API responsiveness

Checking user permissions for API access

Django

class SlowPermission(BasePermission):
    def has_permission(self, request, view):
        # Query database multiple times for each check
        roles_to_check = ['admin', 'moderator']
        for role_name in roles_to_check:
            if UserRole.objects.filter(user=request.user, name=role_name).exists():
                return True
        return False

Multiple database queries per permission check increase server response time and block rendering.

📉 Performance CostBlocks server response for 50-100ms per request depending on DB latency

Performance Comparison

Pattern	DB Queries	Server Delay	Impact on INP	Verdict
Multiple DB queries per check	Many per request	High (50-100ms)	Increases input delay	[X] Bad
Cached roles with single DB query	One per session/request	Low (10-20ms)	Improves input responsiveness	[OK] Good

Rendering Pipeline

Custom permission checks run on the server before content is sent to the browser, affecting server response time and thus the time until the browser can start rendering.

→Server Processing

→Network Transfer

→Browser Rendering Start

⚠️ BottleneckServer Processing due to database queries in permission checks

Core Web Vital Affected

INP

Custom permissions affect server response time and API interaction speed, impacting how quickly permission checks complete before rendering content.

Optimization Tips

1Minimize database queries in permission checks to reduce server delay.

2Cache permission results when possible to improve API responsiveness.

3Avoid complex logic in permission checks that blocks server response.

Performance Quiz - 3 Questions

What is the main performance cost of inefficient custom permissions in Django?

A Large CSS files increasing paint time

B Excessive client-side JavaScript execution

C Multiple database queries causing server delays

D Slow image loading affecting LCP

DevTools: Network and Performance panels

How to check: Use Network panel to measure API response times; use Performance panel to see server response blocking time before first paint.

What to look for: Look for long server response times and delays before content starts rendering indicating slow permission checks.

Practice

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