Object-level permissions concept in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Object-level Permissions in Django

Which statement best describes object-level permissions in Django?

A Permissions that apply to specific instances of a model, controlling access to individual objects.

B Permissions that apply only to the entire Django project settings.

C Permissions that control access to Django admin interface only.

D Permissions that are automatically granted to all users without restrictions.

💡 Hint

Think about permissions that limit access to specific data entries, not the whole model.

Object-level permissions allow fine-grained control by restricting access to individual model instances, unlike model-level permissions which apply to all instances.

❓ component_behavior

intermediate

Behavior of Object-level Permissions with Django REST Framework

Given a Django REST Framework viewset using object-level permissions, what happens when a user tries to access an object they do not have permission for?

A The API returns a 404 Not Found response, hiding the object existence.

B The API returns the object data but with limited fields.

C The API returns a 403 Forbidden response, denying access to that object.

D The API returns a 500 Internal Server Error due to permission failure.

💡 Hint

Consider standard HTTP status codes for permission denial.

When object-level permissions deny access, Django REST Framework returns a 403 Forbidden status to indicate the user is authenticated but not authorized for that object.

📝 Syntax

advanced

Correct Usage of Object-level Permission Class in Django REST Framework

Which of the following code snippets correctly implements an object-level permission class in Django REST Framework?

Django

from rest_framework.permissions import BasePermission

class IsOwner(BasePermission):
    def has_object_permission(self, request, view, obj):
        # Check if the user is the owner of the object
        return obj.owner == request.user

A

class IsOwner(BasePermission):
    def has_permission(self, request, view):
        return obj.owner == request.user

B

class IsOwner(BasePermission):
    def has_object_permission(self, request, view, obj):
        return obj.owner == request.user

C

class IsOwner(BasePermission):
    def has_object_permission(self, request, view, obj):
        return request.user.is_authenticated

D

class IsOwner(BasePermission):
    def has_permission(self, request, view, obj):
        return obj.owner == request.user

💡 Hint

Remember the method name for checking permissions on specific objects.

The method has_object_permission is used to check permissions for individual objects. The method has_permission checks general permissions not tied to an object.

🔧 Debug

advanced

Debugging Object-level Permission Denial in Django

A developer notices that users are always granted access to objects even when they should not have permission. The permission class is:

class IsOwner(BasePermission):
    def has_object_permission(self, request, view, obj):
        return obj.owner == request.user

What is the most likely cause of this issue?

A The permission class should inherit from <code>permissions.IsAuthenticated</code> instead.

B The <code>has_permission</code> method is missing, causing all checks to fail.

C The <code>obj.owner</code> attribute does not exist on the model.

D The viewset does not call <code>check_object_permissions</code> before accessing the object.

💡 Hint

Think about how Django REST Framework enforces object-level permissions in views.

Object-level permissions require the view to call check_object_permissions with the object to enforce the permission check. Without this call, the permission method is not triggered.

❓ state_output

expert

Output of Custom Object-level Permission Logic in Django

Consider this Django REST Framework permission class:

class CustomPermission(BasePermission):
    def has_object_permission(self, request, view, obj):
        match request.method:
            case 'GET' | 'HEAD' | 'OPTIONS':
                return True
            case 'POST' | 'PUT' | 'PATCH' | 'DELETE':
                return obj.owner == request.user
            case _:
                return False

If a user sends a PATCH request to update an object they do not own, what will be the permission check result?

A False, the user is denied permission because they are not the owner.

B True, because PATCH requests are always allowed.

C False, because the method falls into the default case returning False.

D True, because GET, HEAD, and OPTIONS are allowed for all users.

💡 Hint

Look carefully at the match-case logic and which methods require ownership.

The permission allows safe methods (GET, HEAD, OPTIONS) for all users. For modifying methods like PATCH, it checks if the user owns the object. If not, permission is denied.

Practice

1. What is the main purpose of object-level permissions in Django?

easy

A. To speed up database queries

B. To manage user passwords securely

C. To create new database tables automatically

D. To control access to individual data items or objects

Solution

1. Step 1: Understand what object-level permissions mean

   Object-level permissions allow control over access to specific individual objects, not just general models.

2. Step 2: Compare with other options

   Options A, B, and D relate to security, performance, or database structure, not object-level access control.

3. Final Answer:

   To control access to individual data items or objects -> Option D

4. Quick Check:

   Object-level permissions = control individual objects [OK]

Hint: Object-level means per item, not general model access [OK]

Common Mistakes:

• Confusing object-level with model-level permissions
• Thinking it manages passwords or database structure
• Assuming it improves query speed

2. Which of the following is the correct way to check object-level permission for a user in Django using django-guardian?

easy

A. user.has_perm('app.view_model', obj)

B. user.has_perm('app.view_model')

C. user.check_perm('app.view_model', obj)

D. user.can_access('app.view_model', obj)

Solution

1. Step 1: Recall django-guardian permission check syntax

   django-guardian extends Django's has_perm method to accept an object as a second argument for object-level checks.

2. Step 2: Analyze options

   user.has_perm('app.view_model', obj) uses has_perm with object, which is correct. user.has_perm('app.view_model') lacks object, so it's model-level. Options C and D use incorrect method names.

3. Final Answer:

   user.has_perm('app.view_model', obj) -> Option A

4. Quick Check:

   has_perm with object = correct syntax [OK]

Hint: Use has_perm with object argument for object-level checks [OK]

Common Mistakes:

• Omitting the object argument in has_perm
• Using non-existent methods like check_perm or can_access
• Confusing model-level and object-level permission checks

3. Given the code snippet:

from guardian.shortcuts import assign_perm
assign_perm('change_article', user, article)

if user.has_perm('change_article', article):
    print('Can edit')
else:
    print('Cannot edit')

What will be printed if the permission was assigned correctly?

medium

A. Cannot edit

B. Can edit

C. PermissionError

D. No output

Solution

1. Step 1: Understand permission assignment

   The assign_perm function assigns the 'change_article' permission to the user for the specific article object.

2. Step 2: Check permission with has_perm

   The user.has_perm('change_article', article) call returns True because the permission was assigned.

3. Final Answer:

   Can edit -> Option B

4. Quick Check:

   Assigned permission means has_perm returns True [OK]

Hint: Assign permission then has_perm returns True for that object [OK]

Common Mistakes:

• Assuming has_perm returns False without model-level permission
• Expecting exceptions instead of boolean
• Confusing permission names or forgetting object argument

4. Identify the error in this code snippet for checking object-level permission:

if user.has_perm('delete_post'):
    print('Can delete')
else:
    print('Cannot delete')

Assuming you want to check permission on a specific post object.

medium

A. Missing the object argument in has_perm method

B. Using wrong permission name 'delete_post'

C. Should use user.check_perm instead of has_perm

D. No error, code is correct

Solution

1. Step 1: Understand object-level permission check

   To check permission on a specific object, has_perm must include the object as the second argument.

2. Step 2: Analyze the code

   The code calls has_perm without the object, so it checks model-level permission only, not object-level.

3. Final Answer:

   Missing the object argument in has_perm method -> Option A

4. Quick Check:

   Object-level check needs object argument [OK]

Hint: Always pass object to has_perm for object-level checks [OK]

Common Mistakes:

• Forgetting the object argument in has_perm
• Using incorrect method names
• Assuming model-level permission covers object-level

5. You want to allow users to edit only the articles they own. Which approach correctly applies object-level permissions in Django?

hard

A. Use Django's default group permissions without object checks

B. Grant all users the 'change_article' permission globally on the Article model

C. Assign 'change_article' permission to each user only for their own article objects using django-guardian

D. Override the Article model's save method to check user ownership

Solution

1. Step 1: Understand the requirement

   Users should edit only their own articles, so permission must be specific to each article object.

2. Step 2: Evaluate options

   Assign 'change_article' permission to each user only for their own article objects using django-guardian assigns permission per object, matching the requirement. Grant all users the 'change_article' permission globally on the Article model grants global permission, allowing edits on all articles. Use Django's default group permissions without object checks ignores object-level control. Override the Article model's save method to check user ownership is unrelated to permissions.

3. Final Answer:

   Assign 'change_article' permission to each user only for their own article objects using django-guardian -> Option C

4. Quick Check:

   Object-level permission per user per object = Assign 'change_article' permission to each user only for their own article objects using django-guardian [OK]

Hint: Assign permissions per object to enforce ownership editing [OK]

Common Mistakes:

• Granting global permissions instead of per-object
• Ignoring object-level permission packages like django-guardian
• Trying to enforce ownership via model save method