Forem: Muhammad Atif Iqbal

How Authenticator Apps Generate the Same OTP as Your Server (Without Any Communication)

Muhammad Atif Iqbal — Thu, 07 May 2026 11:00:25 +0000

How Authenticator Apps Generate the Same OTP on Authenticator APP as Your Server Without Any Communication between them

One of the most common questions developers ask when learning Multi-Factor Authentication (MFA) is:

How does my server generate the exact same OTP as an authenticator app like Google Authenticator without sending anything to it?

At first, this seems confusing.

You might assume one of these things happens:

The server sends the OTP to the authenticator app
The authenticator app requests the OTP from the server
The server and app somehow communicate in real time

But none of these are true.

The real answer is much more interesting.

The Core Concept

There is no communication between your server and authenticator app during login.

Your server does NOT send OTP to the authenticator app.

Your authenticator app does NOT ask your server for OTP.

Instead, both generate the same OTP independently using mathematics.

This system is called:

Time-Based One-Time Password (TOTP)

It is commonly implemented using libraries such as:

PyOTP (Python)
Speakeasy (Node.js)
OTPAuth

The Real Mechanism

Both your server and authenticator app generate the same OTP because they both have the same three things:

1. The Same Secret

Example:

KZXW6YTBON2GK3TH

This secret is generated by your server when MFA is enabled.

It is then stored:

On your server (database)
Inside the authenticator app

This shared secret is the foundation of the entire system.

2. The Current Time

Example:

3:24:17 PM

Both the server and authenticator app use the current time.

However, this does NOT mean they calculate OTP every second.

We’ll explain that shortly.

3. The Same Algorithm

Both use the same mathematical algorithm.

Conceptually:

OTP = hash(secret + time_window)

This is not the exact formula, but it helps understand the idea.

Because both systems use:

the same secret
the same time
the same algorithm

they produce the same OTP.

Important: It Does NOT Use Exact Seconds

This is where most confusion happens.

Many people assume OTP is generated using exact timestamps like:

3:24:17

3:24:18

If that were true, OTP would change every second.

That would make MFA nearly impossible to use.

Instead, TOTP uses time windows.

Time Windows

Most authenticator systems use:

30-second windows

This means time is divided into 30-second blocks.

Example:

Time Window 1

3:24:00 → 3:24:29

Same OTP for all these seconds.

Time Window 2

3:24:30 → 3:24:59

A new OTP is generated.

Time Window 3

3:25:00 → 3:25:29

Another new OTP.

So if you open your authenticator app at:

3:24:05

and again at:

3:24:27

you will see the exact same OTP.

Because both times fall within the same 30-second window.

Your Exact Scenario

Suppose you try logging in at:

3:23:52 PM

Your server verifies your password and asks for MFA.

You then pick up your phone and open your authenticator app at:

3:24:04 PM

Will it still work?

The answer depends on the time window.

Case 1: Still Within Acceptable Window

If both are effectively verified within the same accepted 30-second range, then:

Server generates:

Authenticator generates:

Case 2: Time Window Changed

Suppose you wait until:

3:24:31 PM

A new time window starts.

Now the OTP becomes:

The previous OTP is no longer valid.

How Systems Handle Delays

Modern MFA systems account for timing differences.

They usually verify against multiple windows.

Typically:

Previous window
Current window
Next window

For example, if current server time is:

3:24:31

the server checks OTPs for:

3:24:00 - 3:24:29
3:24:30 - 3:24:59
3:25:00 - 3:25:29

This handles:

Slight typing delay
Minor clock mismatch
Network latency

This is why MFA remains practical.

The Mathematical Process

Now let’s understand how OTP is actually generated.

Step 1: Convert Time into a Counter

Suppose current Unix timestamp is:

1715077445

Divide by 30:

1715077445 / 30 = 57169248

Take only the integer:

57169248

This becomes the current time counter.

At:

3:24:10

counter might be:

57169248

At:

3:24:22

counter is still:

57169248

So both generate the same OTP.

At:

3:24:31

counter becomes:

57169249

Now OTP changes.

Step 2: Combine Secret + Counter

Example:

KZXW6YTBON2GK3TH + 57169248

Step 3: Apply Cryptographic Hash

The system uses:

HMAC-SHA1

This produces a long encrypted output.

Example:

A82BC9F1E0D...

Step 4: Extract Final 6 Digits

From that output:

This becomes the OTP shown to the user.

Why Both Generate the Same OTP

Because both server and authenticator app use:

The same secret
The same time counter
The same cryptographic algorithm

So they naturally produce the same result.

No communication required.

Real-Life Analogy

Imagine two students.

Both have:

The Same Secret Formula

(secret × window) mod 1000000

Both look at the same wall clock.

If the current 30-second block is:

Both calculate:

(12345 × 48) mod 1000000

Both get:

They never communicate.

They simply used the same formula with the same inputs.

That is exactly how TOTP works.

Why QR Codes Are Used

When a user enables MFA, your server shows a QR code.

The QR code contains the secret.

Example:

otpauth://totp/MyApp:atif@gmail.com?secret=KZXW6YTBON2GK3TH

The authenticator app scans it.

Now the app stores the secret locally.

This is the only time your server and authenticator exchange MFA data.

After this:

No communication is needed.

Why Authenticator Apps Work Offline

Since the app already has:

the secret
the current device time
the algorithm

it can generate OTP offline.

That is why apps like Google Authenticator work even when your phone has:

No internet
Airplane mode enabled
No SIM card

The Biggest Misconception

Many developers think:

❌ The server sends OTP to the authenticator app
❌ The authenticator app asks server for OTP

Neither happens.

The reality is:

Both independently calculate the same OTP using:

OTP = Secret + Time Window + Algorithm

Final Takeaway

The entire MFA mechanism works because your server and authenticator app both share the same secret and use synchronized time windows.

That allows both sides to generate identical OTPs independently.

No API call.

No real-time communication.

Just mathematics.

That is the real mechanism behind authenticator-based MFA.

Mastering Django Rest Framework: A Deep Dive into ViewSets, Routers, and Custom API Architectures

Muhammad Atif Iqbal — Tue, 05 May 2026 10:19:09 +0000

Introduction: The Architecture of a Modern Sports Platform

When building a high-performance backend like the AI Soccer App, the primary challenge isn't just "making it work"—it's making it scalable, secure, and maintainable. In a project that handles everything from AI-driven team analytics to complex Multi-Factor Authentication (MFA), the way you structure your API determines how easily you can add features six months from now.

In this article, we will use our AI Soccer App as a living case study to explore the two primary philosophies of API building in Django: the Explicit Action Pattern (using APIViews) and the Resource Management Pattern (using ViewSets and Routers).

Part 1: The Explicit Action Pattern (The Authentication Case Study)

In our apps/users/ directory, we chose not to use automated routers. Instead, we manually defined every path in urls.py. To understand why, we have to look at the nature of authentication.

Why APIViews for Auth?

Authentication is rarely a standard CRUD (Create, Read, Update, Delete) operation. When a user hits /auth/login/, they aren't "creating" a login object in the database; they are submitting credentials to receive a JWT token. When they hit /auth/verify_otp/, they are performing a validation step in a multi-stage workflow.

The Code Structure

In apps/users/urls.py, we see a dense list of endpoints:

register/
login/
verify_otp/
enable_mfa/
google/ (Social Sign-in)

Each of these points to a specific APIView. This gives us total control. If we need the LoginView to check for suspicious IP addresses or the RegisterView to trigger a welcome email and a background task for AI profile initialization, an APIView provides the cleanest "canvas" to write that logic.

The Pro Tip: Use manual path() definitions when the URL name itself carries specific business meaning that doesn't fit a generic resource name.

Part 2: The Resource Management Pattern (The Teams Case Study)

Moving over to apps/teams/, the philosophy shifts entirely. Here, we are dealing with a classic "Resource." A Team is something that exists in a list, has details, can be edited, and can be deleted.

The Magic of the `DefaultRouter`

By using the DRF DefaultRouter, we reduced our urls.py to essentially one registration line:

router.register(r'teams', TeamViewSet, basename='team')

This single line is incredibly powerful. It tells Django: "I want a standardized RESTful API. Generate the URLs for me." It creates a predictable interface that frontend developers love because it follows the standard convention:

GET /teams/ -> Returns the list.
POST /teams/ -> Creates a new one.
GET /teams/5/ -> Returns details for team #5.

Part 3: To Override or Not to Override?

The most common point of confusion for DRF developers is understanding what happens inside a ModelViewSet. Since it inherits from viewsets.ModelViewSet, it already knows how to perform all standard actions. So why did we rewrite the list, create, retrieve, update, and destroy methods in our TeamViewSet?

The "Formatting" Layer

In our AI Soccer App, we utilize a custom_response() utility. This is a strategic decision for the entire project. By overriding the standard actions, we can ensure that every single response—whether it's a success or a validation error—arrives at the frontend in a beautiful, consistent wrapper.

Consider our list override:

def list(self, request, *args, **kwargs):
    queryset = self.get_queryset()
    serializer = self.get_serializer(queryset, many=True)
    return custom_response(
        data=serializer.data,
        message='Teams retrieved successfully',
        status_code=status.HTTP_200_OK
    )

If we didn't write this, DRF would still return the teams, but the JSON would be "naked." By overriding, we add a message key and a success boolean. This makes the frontend developer's life significantly easier because they can write a single global error handler for the entire app.

Part 4: The Security "Untouchables"

While overriding list() is about presentation, there are three other methods we overrode in the TeamViewSet that are strictly about Logic and Security. These are the "Untouchables"—methods you should almost never remove unless you have a very specific reason.

1. The Multi-Tenancy Shield: `get_queryset()`

In a sports app, privacy is paramount. You don't want a coach from "Team A" seeing the roster and strategy of "Team B."

def get_queryset(self):
    if self.request.user.is_superuser:
        return Team.objects.all()
    return Team.objects.filter(user=self.request.user)

By overriding get_queryset, we implement "Automatic Filtering." The database query itself is limited to only the items owned by the logged-in user. This is a fail-safe; even if a user tries to guess a URL like /teams/999/, the system will return a 404 because that team doesn't exist within the filtered queryset.

2. The Granular Guard: `get_permissions()`

One size does not fit all in permissions. Everyone should be able to see their teams (List/Retrieve), but should they be able to delete them? What if you have a "read-only" staff member?

In our app, we use get_permissions to dynamically switch guards:

def get_permissions(self):
    if self.action in ['update', 'partial_update', 'destroy']:
        return [permissions.IsAuthenticated(), IsOwnerOrSuperAdmin()]
    return [permissions.IsAuthenticated()]

This is a sophisticated pattern. We allow any authenticated user to view the list, but the moment they try to mutate data (Update/Delete), we bring in the IsOwnerOrSuperAdmin permission. This ensures that even if someone finds a way to bypass other checks, they cannot modify data they don't own.

3. The Data Integrity Hook: `perform_create()`

When a user clicks "Create Team," they don't send their own User ID in the JSON body. That would be a security risk (anyone could create a team and assign it to someone else!). Instead, we use perform_create to stitch the data together:

def perform_create(self, serializer):
    serializer.save(user=self.request.user)

This method acts as a "pre-save hook." It takes the validated data from the serializer and injects the user object from the request. This is the gold standard for maintaining data integrity in relational databases.

Part 5: Comparing the Two Worlds

Let's look at a side-by-side comparison of these two methods as implemented in the AI Soccer App.

Feature	`APIView` (Auth App)	`ViewSet` (Teams App)
Logic Type	Process-Oriented	Object-Oriented
URL Setup	Manual and Descriptive	Automatic and Standardized
Code Length	Longer (per endpoint)	Shorter (per resource)
Flexibility	Maximum	High (via overrides)
Best For	Login, Password Reset, OTP	Teams, Players, Matches

Part 6: Best Practices for Growing your API

As your project grows, you will inevitably face the "Fat ViewSet" problem, where your view files become 1000 lines long. Here is how to keep your code as clean as the AI Soccer App:

Move Logic to Serializers: If you find yourself doing complex data validation in the view, move it to the serializer's validate() method.
Use Custom Mixins: If you find yourself repeating the same custom_response logic in 10 different ViewSets, create a ResponseMixin that handles the formatting.
Permissions are Key: Never rely on the frontend for security. Always verify ownership in get_queryset or get_permissions.
Documentation is Free: By using drf-spectacular (as we do in our config/settings.py), your ViewSets automatically generate Swagger documentation. This is only possible because we follow DRF's structured patterns.

Conclusion: The Right Tool for the Job

Building the AI Soccer App taught us that there is no "perfect" way to build an API—only the "right" way for a specific feature.

Use APIViews when you are building a unique experience or a complex workflow like MFA.
Use ViewSets and Routers when you are building a structured management system for your data models.
Always Override for security, multitenancy, and ownership.
Optionally Override for consistent branding and response formatting.

By understanding the lifecycle of a DRF request and knowing exactly which hooks to use, you can build backends that are not only powerful but also a joy to maintain.

What is Robocorp?

Muhammad Atif Iqbal — Tue, 07 Oct 2025 13:30:55 +0000

🧠 1. What is Robocorp?

Robocorp is a platform for building, running, and managing software robots — digital workers that automate repetitive computer tasks.

Also Read Robocorp and RPA: The Complete Guide to Open-Source Robotic Process Automation Using Python

It provides:

Developer tools (like Robocorp Lab or VS Code extensions) for creating automation scripts.
A Python-based framework called Robot Framework or RPA Framework.
Cloud orchestration tools (Control Room) to deploy, schedule, and monitor bots.

Think of it like a modern open-source alternative to tools such as UiPath, Blue Prism, or Automation Anywhere — but built on Python and open standards, not proprietary drag-and-drop systems.

⚙️ 2. What is RPA (Robotic Process Automation)?

RPA (Robotic Process Automation) is the technology that allows software "robots" (bots) to mimic human actions on a computer to complete repetitive tasks.

For example:

Reading invoices from emails and entering them into an ERP system.
Copying data between Excel and a web app.
Logging into websites, downloading reports, and sending them by email.

RPA is mainly used in business process automation — finance, HR, healthcare, etc.

🤖 3. What is Robocorp RPA?

Robocorp RPA means using Robocorp’s ecosystem to build and run RPA bots.

In other words:

It’s Robocorp’s implementation of RPA — built with Python and the open-source RPA Framework libraries.

A Robocorp RPA workflow might:

Use Python + RPA Framework to interact with Excel, PDFs, browsers, or APIs.
Be packaged into a “robot” that runs locally or in Robocorp Control Room (cloud).
Be triggered manually, on a schedule, or by API/webhook.

🧩 Example of Robocorp RPA in action:

Let’s say you want a bot to:

Log into Gmail
Download invoice attachments
Extract data from PDF invoices
Enter data into a Google Sheet

You could write this using Robocorp’s RPA Framework:

from RPA.Email.ImapSmtp import ImapSmtp
from RPA.PDF import PDF
from RPA.Google import Sheets

# Simple workflow

Then deploy it in Robocorp’s Control Room to run every morning — fully automated. 🚀

🆚 In short:

Concept	Description	Example
RPA	Automating repetitive tasks using software robots	Any RPA tool like UiPath
Robocorp	A company/platform providing open-source RPA tools built on Python	robocorp.com
Robocorp RPA	RPA implemented using Robocorp’s tools and RPA Framework	Building Python bots for automation

Django formfield_for_foreignkey() function

Muhammad Atif Iqbal — Fri, 03 Oct 2025 13:50:31 +0000

Mastering Django `formfield_for_foreignkey`: Complete Guide with Examples

Django’s admin is one of its most powerful features. Out of the box, it gives you CRUD forms to create, edit, and manage your models. But sometimes, the default dropdowns for ForeignKey fields are too broad — they list all related objects in the database, which may not always be secure, efficient, or user-friendly.

This is where formfield_for_foreignkey comes in.

In this guide, we’ll cover everything you need to know:

✅ What formfield_for_foreignkey is
✅ How Django handles ForeignKey fields by default
✅ Real-world use cases for overriding it
✅ Advanced examples with filtering, permissions, and tenants
✅ Best practices for production apps
✅ FAQs and troubleshooting tips

By the end, you’ll be able to customize your admin dropdowns to be smarter, safer, and tailored to your business rules.

1. What is formfield_for_foreignkey?

In Django Admin, the method formfield_for_foreignkey(self, db_field, request, **kwargs) is a hook method inside ModelAdmin. It allows you to customize the queryset for ForeignKey dropdown fields in the admin form.

By default, Django lists all related objects in the dropdown. But with this hook, you can:

Filter objects (e.g., only active ones)
Restrict by logged-in user
Sort objects for usability
Enforce multi-tenant separation
Apply role-based visibility rules

Method signature:

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    # custom logic
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

2. How Django Handles ForeignKey by Default

Consider this example:

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

In Django Admin, when creating a Book, the author dropdown will list all authors in the database.

That’s fine for small projects, but:

It can clutter the UI when there are thousands of authors.
It may expose data users shouldn’t see (e.g., other tenants’ data).
It can confuse staff who only need a subset.

This is the default behavior — and exactly where formfield_for_foreignkey helps.

3. Real-World Use Cases

Example 1: Filter by Logged-In User

@admin.register(Book)
class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            kwargs["queryset"] = Author.objects.filter(created_by=request.user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Only authors created by the logged-in user appear in the dropdown.

Example 2: Show Only Active Records

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        kwargs["queryset"] = Author.objects.filter(is_active=True)
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Inactive authors are hidden.

Example 3: Sort Dropdown Alphabetically

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        kwargs["queryset"] = Author.objects.all().order_by("name")
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Users see a clean, ordered dropdown.

Example 4: Restrict by Permissions

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        if request.user.has_perm("app.view_all_authors"):
            kwargs["queryset"] = Author.objects.all()
        else:
            kwargs["queryset"] = Author.objects.filter(created_by=request.user)
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Superusers/managers see all authors.
✅ Staff see only their own.

Example 5: Multi-Tenant Filtering

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "customer":
        kwargs["queryset"] = Customer.objects.filter(tenant=request.user.tenant)
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Each tenant only sees their own customers.

4. When to Use It?

You should override formfield_for_foreignkey when:

You want to limit foreign key options based on logged-in user.
You need to hide irrelevant or sensitive records.
You want to improve usability by sorting or filtering.
You’re working with a multi-tenant app.

5. Best Practices

✅ Always call super() at the end.
✅ Keep queries efficient — avoid heavy joins here.
✅ Apply consistent filtering across forms and lists (get_queryset).
✅ Test with multiple roles (staff, superuser).
✅ Document your filtering logic — future devs will thank you.

6. Common Mistakes

❌ Forgetting to return super() → breaks form rendering.
❌ Overly complex queries → slows down admin.
❌ Inconsistent logic with get_queryset → users see mismatched data.

7. FAQs

Q: Can I filter dropdowns differently for add vs. change forms?
👉 Yes, you can check request.resolver_match or request.path to see the context.

Q: Can I use it for ManyToMany fields?
👉 Use formfield_for_manytomany instead.

Q: Is this the only way to filter foreign keys?
👉 No — you can also use custom ModelForms, but this method is the most admin-friendly.

8. Final Thoughts

Django’s formfield_for_foreignkey is more than just a customization hook — it’s a security and usability tool. By mastering it, you can:

Keep admin dropdowns clean and focused.
Enforce tenant and role-based restrictions.
Prevent accidental data leaks.

'formfield_for_foreignkey()' with Django Permissions: Fine-Grained Control in Admin

Muhammad Atif Iqbal — Fri, 03 Oct 2025 12:56:31 +0000

formfield_for_foreignkey()' with Django## Mastering formfield_for_foreignkey with Django Permissions: Fine-Grained Control in Admin

Django’s admin is famous for giving developers a fully functional interface out of the box. But real-world apps often need fine-grained access control — different users should see different subsets of related objects.

You may already know about formfield_for_foreignkey, a hook that lets you filter ForeignKey dropdowns in Django Admin. But here’s where it gets really powerful: combine it with Django’s built-in permissions and roles to create a role-aware and secure admin.

In this article, we’ll explore:

✅ Why combine formfield_for_foreignkey with permissions
✅ How to restrict dropdowns using has_perm()
✅ Using groups and roles for finer control
✅ Handling sensitive data with custom rules
✅ Multi-tenant use cases
✅ Best practices

What is formfield_for_foreignkey?

Django provides this method inside ModelAdmin classes to customize the queryset for a ForeignKey dropdown. By default, it lists all related objects in the database. But with formfield_for_foreignkey, you can filter, sort, or restrict that list.

Signature:

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    # custom logic here
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

Why Combine with Permissions?

While formfield_for_foreignkey controls what objects appear, Django’s permission system controls who can see what. Combining them means:

Different roles (staff, manager, superuser) see different dropdown options
Sensitive objects can be hidden unless a user has explicit permission
Multi-tenant applications prevent cross-tenant data leaks

Example 1: Restrict by Permission

Suppose you have Author and Book models. Normally, all authors would appear in the dropdown. But maybe only staff with the app.view_all_authors permission should see everyone. Others should see only their own.

from django.contrib import admin
from .models import Author, Book

@admin.register(Book)
class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            if request.user.has_perm("app.view_all_authors"):
                kwargs["queryset"] = Author.objects.all()
            else:
                kwargs["queryset"] = Author.objects.filter(created_by=request.user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Superusers or staff with the permission see all authors.
✅ Other users see only the authors they created.

Example 2: Role-Based Dropdown Filtering

If you’re using Django groups or a role field on your User model, you can scope choices based on role.

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        if request.user.groups.filter(name="Managers").exists():
            # Managers see all active authors
            kwargs["queryset"] = Author.objects.filter(is_active=True)
        else:
            # Regular staff only see their own active authors
            kwargs["queryset"] = Author.objects.filter(
                created_by=request.user, is_active=True
            )
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Managers have broader visibility.
✅ Staff stay scoped to their own data.

Example 3: Handling Sensitive Data

Sometimes you want to hide sensitive objects unless the user has explicit permission.

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "project":
        qs = Project.objects.filter(is_active=True)

        if not request.user.has_perm("app.can_assign_sensitive_projects"):
            qs = qs.exclude(is_sensitive=True)

        kwargs["queryset"] = qs
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Sensitive projects don’t even appear in the dropdown unless allowed.

Example 4: Multi-Tenant Use Case

In SaaS apps with multiple tenants, you can combine tenant ownership with permissions.

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "customer":
        qs = Customer.objects.filter(tenant=request.user.tenant)

        if not request.user.has_perm("app.view_inactive_customers"):
            qs = qs.filter(is_active=True)

        kwargs["queryset"] = qs
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Users only see customers from their tenant.
✅ Optional permission controls visibility of inactive customers.

Best Practices

Always call super() at the end to retain Django’s defaults.
Keep queries efficient — avoid heavy joins inside this method.
Test with multiple roles (staff, manager, superuser) to avoid hidden bugs.
Stay consistent — if you filter dropdowns here, apply the same logic in get_queryset() for list views.

Final Thoughts

formfield_for_foreignkey gives you object-level filtering power, while Django’s permission system gives you user-level control. Together, they create an admin that’s secure, role-aware, and tenant-safe.

Whether you’re managing sensitive data, building a SaaS app, or just keeping the admin clean for staff, mastering this combination will make your Django admin much more robust.

👉 With these examples, you can now:

Use permissions to decide who sees what in dropdowns.
Implement role-based logic with groups.
Keep your admin secure in multi-tenant and sensitive-data scenarios.

How to Restrict ForeignKey Choices in Django

Muhammad Atif Iqbal — Fri, 03 Oct 2025 11:22:06 +0000

Introduction

If you’ve ever built an application with Django Admin, you’ve probably used dropdowns for related models. These dropdowns appear whenever you have a ForeignKey field.

Read this article aslo How to Restrict ForeignKey Choices in Django

But here’s the problem:
By default, Django Admin will show all related objects in that dropdown.

What if you only want to show the objects created by the logged-in user?
Or maybe you want staff users to only see certain options?
Or perhaps you need to filter choices based on business logic (like only “active” records)?

If you landed here by searching things like:

“Django admin limit dropdown choices”
“How to restrict ForeignKey options per user in Django”
“Django admin filter related objects dynamically”
“Restrict choices in Django admin form”
“How to show limited foreign key options in Django”

👉 Then this article is exactly for you.

The solution lies in a powerful Django Admin method:
formfield_for_foreignkey(self, db_field, request, **kwargs)

In this article, we’ll explore:

Why Django shows all ForeignKey objects by default
How to filter dropdown choices in the admin
Step-by-step examples with code
Alternative approaches (querysets, limit_choices_to)
Best practices for performance & maintainability
Common pitfalls & FAQs

By the end, you’ll know exactly how to control your admin dropdowns like a pro.

Why Does Django Show All ForeignKey Choices by Default?

When Django sees a ForeignKey in your model, it automatically renders a dropdown in the Admin. For example:

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

In the Book Admin form, Django will render a dropdown for author.

But by default:

It will show all authors from the database.
Even if you only want to allow some of them.

That’s fine for small projects, but in real-world apps, you often need restrictions.

When Do You Need to Restrict ForeignKey Choices?

Here are some common use cases where you might want to filter ForeignKey dropdowns in Django Admin:

User-specific data

Example: Only show Projects created by the logged-in user.
Useful in multi-tenant apps.

Role-based filtering

Example: Staff can only assign orders to employees in their department.

Status-based filtering

Example: Only show “active” categories, not archived ones.

Security restrictions

Example: Prevent staff users from accessing other users’ data.

Performance reasons

If you have thousands of related objects, filtering avoids slow dropdowns.

The Django Way: Using `formfield_for_foreignkey`

Django gives us a built-in method for this exact problem:
formfield_for_foreignkey(self, db_field, request, **kwargs)

This method is part of the ModelAdmin class and runs whenever Django builds a form field for a ForeignKey.

Method Signature

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    # your logic here
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

db_field → the field object (so you can check if it’s the field you want to customize).
request → the current HTTP request (so you can check the logged-in user).
kwargs → extra options passed to the form field.

Example 1: Restrict Choices to Logged-in User

Let’s say each Book belongs to an Author, and you want a user to only select themselves as the author.

from django.contrib import admin
from .models import Book, Author

class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            kwargs["queryset"] = Author.objects.filter(user=request.user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

admin.site.register(Book, BookAdmin)

✔ Now, the dropdown for author will only show authors tied to the logged-in user.

Example 2: Restrict Choices Based on User Role

Let’s say staff users should only see authors in their department.

class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author" and not request.user.is_superuser:
            kwargs["queryset"] = Author.objects.filter(department=request.user.department)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✔ Superusers see all authors, staff see filtered ones.

Example 3: Show Only Active Records

class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            kwargs["queryset"] = Author.objects.filter(is_active=True)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✔ Only active authors appear in the dropdown.

Alternative Approaches

Sometimes you don’t need formfield_for_foreignkey. Here are other options:

1. Using `limit_choices_to` in the Model

class Book(models.Model):
    author = models.ForeignKey(
        Author, 
        on_delete=models.CASCADE,
        limit_choices_to={'is_active': True}
    )

⚠️ Downside: This is static — you can’t use the logged-in user or request context.

2. Overriding the Form Class

You can also customize choices in the form itself:

from django import forms
from .models import Book, Author

class BookForm(forms.ModelForm):
    class Meta:
        model = Book
        fields = "__all__"

    def __init__(self, *args, **kwargs):
        user = kwargs.pop('request').user
        super().__init__(*args, **kwargs)
        self.fields['author'].queryset = Author.objects.filter(user=user)

Then plug the form into your admin:

class BookAdmin(admin.ModelAdmin):
    form = BookForm

Best Practices

✅ Use formfield_for_foreignkey if you need request-aware filtering.
✅ Use limit_choices_to for static filters.
✅ Cache querysets if you expect heavy load.
✅ Always allow superusers full access.

Common Pitfalls

Forgetting super()
Always call the parent method, otherwise you may break Django’s defaults.
Filtering too aggressively
If you filter incorrectly, you might prevent staff from editing old data.
Performance issues
Large querysets in dropdowns can slow down admin forms — add filters wisely.

FAQs

❓ Can I restrict ForeignKey dropdowns outside the admin?

Yes — in custom forms, override the __init__ method and filter querysets.

❓ Can I hide the dropdown completely?

Yes — you can set readonly_fields or replace the field with a custom widget.

❓ What if I want autocomplete instead of dropdown?

Use autocomplete_fields in your ModelAdmin. It works well with large datasets.

Conclusion

Restricting ForeignKey choices in Django Admin is a common real-world need.
And Django makes it easy with the formfield_for_foreignkey method.

So whether you searched for:

“How to filter related objects in Django admin form”
“Django admin restrict choices dynamically per user”
“Limit ForeignKey dropdown in Django”

👉 This guide gives you the complete solution.

By overriding formfield_for_foreignkey, you can:

Filter dropdowns per user
Apply role-based restrictions
Improve performance
Keep your admin secure

Read this article aslo How to Restrict ForeignKey Choices in Django

`formfield_for_foreignkey()` in Django Admin: A Complete Guide

Muhammad Atif Iqbal — Fri, 03 Oct 2025 10:22:25 +0000

Mastering `formfield_for_foreignkey` in Django Admin: A Complete Guide

Django’s admin is one of its most powerful features. Out of the box, it gives you forms to create, edit, and manage your models. But sometimes, the default dropdowns for ForeignKey fields are too permissive — they show all related objects in the database.

What if you want to restrict the choices a user can see, based on who is logged in, or some business logic?

That’s where formfield_for_foreignkey comes in.

Read this aticle also formfield_for_foreignkey in Django

In this article, we’ll dive into:

✅ What is formfield_for_foreignkey?
✅ How Django handles ForeignKey fields by default
✅ Real-world examples of overriding formfield_for_foreignkey
✅ When and why you should use it
✅ Best practices

🔎 What is `formfield_for_foreignkey` in Django Admin?

In Django Admin, the method formfield_for_foreignkey(self, db_field, request, **kwargs) is a hook method that lets you customize the queryset for ForeignKey dropdown fields in the admin form.

By default, Django will show all objects of the related model.
With this method, you can filter, sort, or limit the available options.

Method signature:

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    # custom logic
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

🛠 How Django Handles ForeignKey by Default

Imagine we have two models:

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

In the Django Admin, when creating a Book, the author dropdown will list all authors in the database.
This is the default behavior.

But what if you only want staff users to see authors they created? That’s where you override formfield_for_foreignkey.

🚀 Example 1: Filter ForeignKey Choices by Logged-in User

from django.contrib import admin
from .models import Book, Author

@admin.register(Book)
class BookAdmin(admin.ModelAdmin):

    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == "author":
            # Only show authors created by the logged-in user
            kwargs["queryset"] = Author.objects.filter(created_by=request.user)
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Now, when a staff user opens the Book form, the author dropdown only lists the authors they created.
Superusers will still see everything.

🚀 Example 2: Show Only Active Related Objects

Sometimes you want to show only active records.

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        kwargs["queryset"] = Author.objects.filter(is_active=True)
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

✅ Now, inactive authors won’t appear in the dropdown.

🚀 Example 3: Sort the Dropdown Options

You can also order the queryset to make the dropdown more user-friendly:

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == "author":
        kwargs["queryset"] = Author.objects.all().order_by("name")
    return super().formfield_for_foreignkey(db_field, request, **kwargs)

🔑 When Should You Use `formfield_for_foreignkey`?

You should override this method when:

You want to restrict foreign key options based on the logged-in user.
You need to hide inactive or irrelevant related objects.
You want to improve usability by sorting or limiting dropdown choices.
You are working in a multi-tenant application where users should not see each other’s data.

⚡ Best Practices

Always call super() at the end so Django can apply its defaults.
Be careful with queries — don’t run expensive queries inside this method.
Test both staff and superuser accounts to ensure permissions work as expected.
Keep the logic simple — if the filtering is very complex, consider using custom forms instead.

🎯 Final Thoughts

The formfield_for_foreignkey method is one of the most useful hooks in Django Admin. It gives you control over what appears in your ForeignKey dropdowns, making your admin interface safer, more user-friendly, and tenant-aware.

Whether you’re building a small project or a large SaaS app, mastering this hook will save you a lot of time and prevent accidental data leaks.

✅ With this article, you can now:

Explain what formfield_for_foreignkey is.
Customize dropdowns for different use cases.
Improve your Django admin forms for better usability and security.

Read this aticle also formfield_for_foreignkey in Django

Demystifying db_field in Django Admin

Muhammad Atif Iqbal — Thu, 02 Oct 2025 12:55:53 +0000

When working with Django Admin, you’ll often need to customize how fields appear in your forms. Django provides hooks such as formfield_for_foreignkey, formfield_for_choice_field, and formfield_for_dbfield — all of which receive an argument called db_field.

If you’ve ever wondered what exactly db_field is and how you can use it, this article is for you.

For complete article please visit db_field in Django Admin

What is `db_field`?

In short, db_field is the model field object being processed when Django builds the admin form.

When you define a model:

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

Django Admin inspects each field (title, author, etc.) when rendering the form. At that point, it passes the actual field instance (a CharField or ForeignKey) to your override methods as db_field.

So:

For Book.title → db_field will be a CharField instance.
For Book.author → db_field will be a ForeignKey instance.

Where is `db_field` Used?

The db_field argument appears in several admin customization methods:

formfield_for_foreignkey(self, db_field, request, **kwargs)
→ Lets you change how ForeignKey fields are displayed.
formfield_for_choice_field(self, db_field, request, **kwargs)
→ Lets you modify dropdowns created from choices.
formfield_for_dbfield(self, db_field, request, **kwargs)
→ A generic hook for any field type.

Example 1 — Filtering a ForeignKey

Imagine you want to limit which authors appear in the dropdown when creating a book.

from django.contrib import admin

class BookAdmin(admin.ModelAdmin):
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        # Only customize the "author" field
        if db_field.name == "author":
            kwargs["queryset"] = Author.objects.filter(name__startswith="A")
        return super().formfield_for_foreignkey(db_field, request, **kwargs)

🔎 What’s happening?

Django passes the Book.author field as db_field.
We check db_field.name == "author".
Then we override its queryset to only show authors whose names start with “A”.

Example 2 — Customizing Choices

Suppose you have a field with predefined choices:

class Book(models.Model):
    GENRE_CHOICES = [
        ("fiction", "Fiction"),
        ("nonfiction", "Non-Fiction"),
        ("poetry", "Poetry"),
    ]
    title = models.CharField(max_length=200)
    genre = models.CharField(max_length=20, choices=GENRE_CHOICES)

You can alter how these choices appear in admin:

class BookAdmin(admin.ModelAdmin):
    def formfield_for_choice_field(self, db_field, request, **kwargs):
        if db_field.name == "genre":
            # Reorder or filter choices
            kwargs["choices"] = [
                ("fiction", "Fiction"),
                ("poetry", "Poetry"),
            ]
        return super().formfield_for_choice_field(db_field, request, **kwargs)

Example 3 — Catch-All with `formfield_for_dbfield`

If you want to apply a rule to all fields, use formfield_for_dbfield:

class BookAdmin(admin.ModelAdmin):
    def formfield_for_dbfield(self, db_field, request, **kwargs):
        # Example: add placeholder text to all CharFields
        if isinstance(db_field, models.CharField):
            kwargs["widget"].attrs["placeholder"] = f"Enter {db_field.verbose_name}"
        return super().formfield_for_dbfield(db_field, request, **kwargs)

Here, every CharField in the model gets a placeholder in its admin input box.

Why is `db_field` Useful?

🎯 Granular Control — target individual fields like author or genre.
👥 User-Specific Filtering — restrict dropdowns per user role.
🛠 Custom Widgets — attach custom widgets or attributes.
🧹 Centralized Logic — all customization stays inside ModelAdmin.

Key Takeaways

db_field is the actual field object from your model.
Django sends it to hooks so you can inspect the field and modify its admin form behavior.
Use:
- formfield_for_foreignkey → control ForeignKey dropdowns.
- formfield_for_choice_field → control choices.
- formfield_for_dbfield → catch-all for any field type.

✅ By leveraging db_field, you can transform the Django Admin from a basic CRUD tool into a finely tuned interface that enforces business rules and improves usability.

What is threading in Python?

Muhammad Atif Iqbal — Mon, 15 Sep 2025 13:49:53 +0000

🔹 What is threading in Python?

Threading means running multiple threads of execution within the same process.
A thread is the smallest unit of a program that can run independently.
In Python, threads are often used for tasks like:
- Handling multiple user requests in a web server.
- Running background tasks (like sending emails, logging, or processing data).
- Improving responsiveness (so the program doesn’t “freeze” while waiting for something).

👉 Example:

import threading
import time

def worker(name):
    print(f"{name} started")
    time.sleep(2)
    print(f"{name} finished")

# Create 2 threads
t1 = threading.Thread(target=worker, args=("Thread-1",))
t2 = threading.Thread(target=worker, args=("Thread-2",))

t1.start()
t2.start()

This runs two “workers” at the same time (interleaved).

🔹 Why use threading in Django?

Django (and many web servers like Gunicorn or Uvicorn) may serve multiple users at once.
Each request may be handled by a different thread.
If you need some data specific to a request/thread (like which website/domain is being used), you can store it in thread-local storage so that it doesn’t get mixed up with another request.

🔹 What is `_thread_local`?

_thread_local = threading.local()

threading.local() creates a thread-local storage object.
That means each thread can store its own attributes without interfering with other threads.
_thread_local is just a variable name (the underscore _ is a Python convention meaning “this is private, internal use”).

👉 Example:

import threading

local_data = threading.local()

def worker(name):
    local_data.value = name
    print(f"In {name}, local_data.value = {local_data.value}")

t1 = threading.Thread(target=worker, args=("Thread-1",))
t2 = threading.Thread(target=worker, args=("Thread-2",))

t1.start()
t2.start()

Each thread has its own local_data.value → no conflict.

✅ Summary in plain words:

Threading = running multiple requests at once.
threading.local() = keeps request-specific data separate.
_thread_local.current_website = acts like a per-request global variable.
Underscore _ = naming convention meaning “internal use only”.

What is a Decorator in Python, Django and FastAPI?

Muhammad Atif Iqbal — Thu, 04 Sep 2025 12:02:51 +0000

🔹 Decorators in Python, Django and FastAPI in details with examples

In Python, a decorator is a function that wraps another function or class to modify or extend its behavior without changing its code directly.

Think of it like:

“A decorator takes a function/class as input → adds some extra functionality → and returns a new function/class.”

🔹 Example 1 – Simple function decorator

def my_decorator(func):
    def wrapper():
        print("Before function runs")
        func()
        print("After function runs")
    return wrapper

@my_decorator   # same as: hello = my_decorator(hello)
def hello():
    print("Hello, World!")

hello()

Output:

Before function runs
Hello, World!
After function runs

Here:

@my_decorator wraps the hello() function.
When you call hello(), actually wrapper() runs.

🔹 Example 2 – Decorator with arguments

def repeat(n):
    def decorator(func):
        def wrapper(*args, **kwargs):
            for _ in range(n):
                func(*args, **kwargs)
        return wrapper
    return decorator

@repeat(3)   # repeat hello 3 times
def hello(name):
    print(f"Hello {name}!")

hello("Atif")

Output:

Hello Atif!
Hello Atif!
Hello Atif!

🔹 Example 3 – Django decorator

In Django, you’ve seen things like:

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

Here @login_required ensures that only logged-in users can access that view.

🔹 Example 4 – Class decorator (Django admin)

In your admin file, you saw:

@admin.register(Payment)
class PaymentAdmin(admin.ModelAdmin):
    ...

This is a class decorator.
It tells Django: “Register the Payment model in the admin, using this custom admin class.”

Equivalent without decorator:

class PaymentAdmin(admin.ModelAdmin):
    ...

admin.site.register(Payment, PaymentAdmin)

🔹 Example 5 – FastAPI decorator

In FastAPI, routes are defined with decorators:

from fastapi import FastAPI

app = FastAPI()

@app.get("/hello")
def say_hello():
    return {"msg": "Hello World"}

Here @app.get("/hello") is a decorator that says: “When someone sends a GET request to /hello, call this function.”

✅ Summary for decorators:

Decorators = wrappers that extend/modify behavior of functions/classes.
They’re widely used in Django (admin, views, permissions) and FastAPI (routes, middlewares).

how to write your own decorator step by step

Let’s build your own decorators step by step.
We’ll start from very basic → then add arguments → then apply in Django-like use cases.

🛠 Step 1: Basic decorator

def simple_decorator(func):
    def wrapper():
        print("👉 Before the function")
        func()
        print("👉 After the function")
    return wrapper

@simple_decorator
def say_hello():
    print("Hello Atif!")

say_hello()

Output:

👉 Before the function
Hello Atif!
👉 After the function

📌 Here:

@simple_decorator is applied to say_hello.
When you call say_hello(), Python actually runs wrapper().

🛠 Step 2: Decorator for any function with arguments

def log_args(func):
    def wrapper(*args, **kwargs):
        print(f"Function {func.__name__} called with args={args}, kwargs={kwargs}")
        return func(*args, **kwargs)   # run the real function
    return wrapper

@log_args
def add(a, b):
    return a + b

print(add(3, 5))

Output:

Function add called with args=(3, 5), kwargs={}
8

🛠 Step 3: Decorator with arguments

Sometimes you want to pass options to your decorator itself.

def repeat(n):
    def decorator(func):
        def wrapper(*args, **kwargs):
            for i in range(n):
                print(f"Run {i+1} of {n}")
                func(*args, **kwargs)
        return wrapper
    return decorator

@repeat(3)   # repeat the function 3 times
def greet(name):
    print(f"Hello {name}")

greet("Atif")

Output:

Run 1 of 3
Hello Atif
Run 2 of 3
Hello Atif
Run 3 of 3
Hello Atif

Decorator in Django

🛠 A Django-like decorator

Let’s make our own login_required style decorator:

def my_login_required(func):
    def wrapper(request, *args, **kwargs):
        if not getattr(request, "user", None):   # check if request has a user
            return "❌ User not logged in!"
        return func(request, *args, **kwargs)
    return wrapper

# fake request objects
class Request:
    def __init__(self, user=None):
        self.user = user

@my_login_required
def dashboard(request):
    return f"Welcome {request.user}!"

print(dashboard(Request()))        # no user
print(dashboard(Request("Atif")))  # with user

Output:

❌ User not logged in!
Welcome Atif!

🛠 Using class decorator (like Django Admin)

def register_model(model_name):
    def decorator(admin_class):
        print(f"✅ Registered {model_name} with admin class {admin_class.__name__}")
        return admin_class
    return decorator

@register_model("Payment")
class PaymentAdmin:
    pass

Output:

✅ Registered Payment with admin class PaymentAdmin

📌 This is exactly how @admin.register(Model) works internally.

✅ Summary for Django Decorators:

A decorator is a function that wraps another function/class.
@decorator_name is just shorthand for function = decorator_name(function).
They’re useful for authentication checks, logging, caching, registering routes/admins, etc.

decorators in FastAPI.

They work the same as Python decorators, but in FastAPI they’re often used for middleware-like behavior (before/after running your endpoint).

🛠 Example 1: Simple logging decorator

from fastapi import FastAPI

app = FastAPI()

# Custom decorator
def log_request(func):
    async def wrapper(*args, **kwargs):
        print(f"👉 Calling endpoint: {func.__name__}")
        result = await func(*args, **kwargs)
        print(f"✅ Finished endpoint: {func.__name__}")
        return result
    return wrapper

@app.get("/hello")
@log_request
async def say_hello():
    return {"message": "Hello Atif!"}

When you visit /hello:

👉 Calling endpoint: say_hello
✅ Finished endpoint: say_hello

🛠 Example 2: Decorator to check API Key

from fastapi import FastAPI, Request, HTTPException

app = FastAPI()

def require_api_key(func):
    async def wrapper(request: Request, *args, **kwargs):
        api_key = request.headers.get("X-API-Key")
        if api_key != "secret123":
            raise HTTPException(status_code=403, detail="Invalid API Key")
        return await func(request, *args, **kwargs)
    return wrapper

@app.get("/secure")
@require_api_key
async def secure_endpoint(request: Request):
    return {"message": "You are authorized!"}

🔑 If you call /secure without X-API-Key: secret123, you’ll get:

{"detail": "Invalid API Key"}

🛠 Example 3: Decorator with arguments (rate limiter style)

import time
from fastapi import FastAPI, HTTPException

app = FastAPI()

def rate_limit(seconds: int):
    last_called = {}

    def decorator(func):
        async def wrapper(*args, **kwargs):
            now = time.time()
            if func.__name__ in last_called and now - last_called[func.__name__] < seconds:
                raise HTTPException(status_code=429, detail="Too many requests")
            last_called[func.__name__] = now
            return await func(*args, **kwargs)
        return wrapper
    return decorator

@app.get("/ping")
@rate_limit(5)   # limit calls to every 5 seconds
async def ping():
    return {"message": "pong!"}

First request works ✅
Second request within 5s → 429 Too Many Requests

🛠 Example 4: Class decorator for routes (like Django’s `@admin.register`)

def tag_routes(tag: str):
    def decorator(func):
        func._tag = tag  # attach metadata
        return func
    return decorator

app = FastAPI()

@app.get("/items")
@tag_routes("inventory")
async def get_items():
    return {"items": ["apple", "banana"]}

# Later you could inspect `get_items._tag` == "inventory"

✅ Summary for FastAPI decorators

Work same as Python decorators
Useful for:
- Logging
- Auth / API keys
- Rate limiting
- Attaching metadata
You can mix them with FastAPI’s built-in dependencies, but decorators give more fine-grained control.

Arrays, Lists, Dicts, and Sets Across Python, C++, and JavaScript

Muhammad Atif Iqbal — Tue, 02 Sep 2025 11:52:23 +0000

Comparison of Arrays, Lists, Dicts, and Sets Across Python, C++, and JavaScript

✅ 1. Arrays vs Dicts in Each Language

Concept	Python	C++	JavaScript
Array / List	`list = [10, 20, 30]`	`int arr[3] = {10, 20, 30};` or `vector<int> arr = {10, 20, 30};`	`let arr = [10, 20, 30];`
Dictionary / Map (Key-Value)	`d = {"a": 1, "b": 2}`	`map<string, int> d = {{"a", 1}, {"b", 2}};`	`let d = {a: 1, b: 2};` or `let d = new Map([["a", 1], ["b", 2]]);`
Set (Unique elements, unordered)	`s = {1, 2, 3}`	`set<int> s = {1, 2, 3};`	`let s = new Set([1, 2, 3]);`

✅ 2. Why "Array" is called "List" in Python & JavaScript

In C++, array is a low-level fixed-size container. Example:

  int arr[3] = {1, 2, 3}; // Size is 3, cannot change

In Python and JavaScript, arrays are dynamic and resizable, so they are closer to C++ vector:

  arr = [1, 2, 3]
  arr.append(4)   # can grow

  let arr = [1, 2, 3];
  arr.push(4);   // can grow

👉 That’s why Python calls it list, not array, because it’s flexible.
👉 JS still calls it Array, but it behaves like a Python list.

✅ 3. Why C++ Arrays are Declared with `{}` not `[]`

Square brackets [] → specify size/index.

  int arr[3]; // array of size 3

Curly braces {} → specify values for initialization.

  int arr[3] = {10, 20, 30}; // initialize

So:

[] → size
{} → values

✅ 4. C++ 3D Array Example

A 3D array = array of arrays of arrays.
Example: a cube 2 × 3 × 4

#include <iostream>
using namespace std;

int main() {
    int arr[2][3][4] = {
        { {1, 2, 3, 4}, {5, 6, 7, 8}, {9, 10, 11, 12} },
        { {13, 14, 15, 16}, {17, 18, 19, 20}, {21, 22, 23, 24} }
    };

    cout << arr[1][2][3];  // Output: 24
}

👉 Think of it as a box with 2 layers, each having 3 rows, each row having 4 columns.

✅ 5. Sets in Each Language

Python

  s = {1, 2, 3, 3}
  print(s)  # {1, 2, 3} (removes duplicates)

C++

  #include <set>
  set<int> s = {1, 2, 3, 3};
  for (int x : s) cout << x << " ";  // 1 2 3

JavaScript

  let s = new Set([1, 2, 3, 3]);
  console.log(s);  // Set(3) {1, 2, 3}

👉 Difference with {} in Python

{} in Python by default = dict (empty dictionary).
set() must be used for empty set.

a = {}       # dictionary
b = set()    # empty set

👉 In C++ {} is not a set—it’s array initializer.

✅ 6. Quick Example Comparison

Array / List

Python: arr = [10, 20, 30]
C++: int arr[3] = {10, 20, 30};
JS: let arr = [10, 20, 30];

Dictionary / Map

Python: {"x": 1, "y": 2}
C++: map<string, int> d = {{"x",1},{"y",2}};
JS: {x:1, y:2} or new Map([["x",1],["y",2]])

Set

Python: {1, 2, 3}
C++: set<int> s = {1, 2, 3};
JS: new Set([1, 2, 3])

✅ So summary:

C++ arrays = low-level, fixed size.
Python list / JS Array = dynamic array (like C++ vector).
Dict/Map = key-value store (different thing).
Set = unique elements in all three.

Django vs Flask vs FastAPI

Muhammad Atif Iqbal — Mon, 01 Sep 2025 15:00:07 +0000

Django vs Flask vs FastAPI: A Complete Comparison

When building a web application in Python, three popular frameworks often come up in discussions: Django, Flask, and FastAPI. Each has its own strengths, weaknesses, and use cases. Choosing the right one depends on your project requirements, scalability goals, and developer experience.

1. Django

Overview

Django is a high-level, full-stack web framework designed for rapid development. It comes with batteries-included philosophy, meaning most of the essential features (ORM, authentication, admin panel) are built-in.

Key Features

Built-in ORM for database operations
Authentication and Authorization out of the box
Admin interface for managing data
Template engine for rendering HTML
Follows MTV (Model-Template-View) pattern

Pros

Great for large projects needing structure
Mature ecosystem with lots of third-party packages
Strong community and documentation
Excellent for applications where you need an admin panel and a lot of built-in tools

Cons

Heavyweight compared to Flask and FastAPI
Less flexible (you often need to follow Django’s way of doing things)
Not as fast as FastAPI for APIs

Best Use Cases

Enterprise applications
Content-heavy websites (CMS, e-commerce)
Projects where rapid prototyping with an admin panel is needed

2. Flask

Overview

Flask is a lightweight, micro web framework. Unlike Django, it doesn’t force you to use an ORM or specific tools. It’s very flexible and lets developers pick their own components.

Key Features

Minimal, simple, and easy to get started
Jinja2 templating engine
Extensions available for ORM (SQLAlchemy), authentication, etc.
Designed for flexibility

Pros

Very lightweight and flexible
Easy to learn and understand
Perfect for small APIs or web apps
Great choice when you need full control over architecture

Cons

No built-in ORM, authentication, or admin (everything must be added manually)
Can lead to “reinventing the wheel” for larger apps
Not the fastest (synchronous, unless extended with async libraries)

Best Use Cases

Small to medium APIs
Prototypes and learning projects
Apps where you need complete freedom in choosing tools

3. FastAPI

Overview

FastAPI is a modern, high-performance web framework for building APIs with Python. It’s built on Starlette (for the web parts) and Pydantic (for data validation). It is designed with asynchronous support and automatic OpenAPI/Swagger documentation.

Key Features

Built-in async/await support
Automatic generation of interactive API docs (Swagger & ReDoc)
Strong typing with Pydantic models
Extremely fast performance (comparable to Node.js and Go)

Pros

Very fast (close to raw Starlette speed)
Great for modern APIs and microservices
Automatic validation and documentation saves time
Strong typing makes debugging and scaling easier

Cons

Relatively younger framework (less mature ecosystem than Django/Flask)
Smaller community compared to Django
Not ideal for traditional monolithic web apps with templates and admin

Best Use Cases

REST APIs and microservices
Real-time applications (chat, IoT, etc.)
Machine Learning/AI apps (where performance matters)

4. Performance Comparison

Feature	Django 🟦	Flask 🟧	FastAPI 🟩
Learning Curve	Moderate	Easy	Moderate
Performance	Medium	Medium	High
Async Support	Limited	Partial	Native
Built-in Tools	Many	Few	Moderate
Community & Ecosystem	Large	Large	Growing
Best for	Full apps	Small apps	APIs & microservices

5. Which One Should You Choose?

Choose Django if you’re building a large web application with a database, admin panel, and built-in tools. (e.g., e-commerce site, CMS, ERP)
Choose Flask if you need a simple, lightweight solution or you want full control with minimal dependencies. (e.g., small APIs, prototypes)
Choose FastAPI if you’re building modern APIs or microservices where speed and scalability matter. (e.g., ML model serving, real-time apps)

✅ In short:

Django = batteries included (big projects, admin dashboards)
Flask = flexibility (small projects, learning, custom solutions)
FastAPI = speed & modern APIs (microservices, AI/ML backends)

Forem: Muhammad Atif Iqbal

How Authenticator Apps Generate the Same OTP as Your Server (Without Any Communication)

How Authenticator Apps Generate the Same OTP on Authenticator APP as Your Server Without Any Communication between them

The Core Concept

The Real Mechanism

1. The Same Secret

2. The Current Time

3. The Same Algorithm

Important: It Does NOT Use Exact Seconds

Time Windows

Time Window 1

Time Window 2

Time Window 3

Your Exact Scenario

Case 1: Still Within Acceptable Window

Case 2: Time Window Changed

How Systems Handle Delays

The Mathematical Process

Step 1: Convert Time into a Counter

Step 2: Combine Secret + Counter

Step 3: Apply Cryptographic Hash

Step 4: Extract Final 6 Digits

Why Both Generate the Same OTP

Real-Life Analogy

The Same Secret Formula

Why QR Codes Are Used

Why Authenticator Apps Work Offline

The Biggest Misconception

Final Takeaway

Mastering Django Rest Framework: A Deep Dive into ViewSets, Routers, and Custom API Architectures

Introduction: The Architecture of a Modern Sports Platform

Part 1: The Explicit Action Pattern (The Authentication Case Study)

Why APIViews for Auth?

The Code Structure

Part 2: The Resource Management Pattern (The Teams Case Study)

The Magic of the DefaultRouter

Part 3: To Override or Not to Override?

The "Formatting" Layer

Part 4: The Security "Untouchables"

1. The Multi-Tenancy Shield: get_queryset()

2. The Granular Guard: get_permissions()

3. The Data Integrity Hook: perform_create()

Part 5: Comparing the Two Worlds

Part 6: Best Practices for Growing your API

Conclusion: The Right Tool for the Job

What is Robocorp?

🧠 1. What is Robocorp?

Also Read Robocorp and RPA: The Complete Guide to Open-Source Robotic Process Automation Using Python

⚙️ 2. What is RPA (Robotic Process Automation)?

🤖 3. What is Robocorp RPA?

🧩 Example of Robocorp RPA in action:

🆚 In short:

Django formfield_for_foreignkey() function

Mastering Django formfield_for_foreignkey: Complete Guide with Examples

1. What is formfield_for_foreignkey?

2. How Django Handles ForeignKey by Default

3. Real-World Use Cases

Example 1: Filter by Logged-In User

Example 2: Show Only Active Records

Example 3: Sort Dropdown Alphabetically

Example 4: Restrict by Permissions

Example 5: Multi-Tenant Filtering

4. When to Use It?

5. Best Practices

6. Common Mistakes

7. FAQs

8. Final Thoughts

'formfield_for_foreignkey()' with Django Permissions: Fine-Grained Control in Admin

What is formfield_for_foreignkey?

Why Combine with Permissions?

Example 1: Restrict by Permission

Example 2: Role-Based Dropdown Filtering

Example 3: Handling Sensitive Data

Example 4: Multi-Tenant Use Case

Best Practices

Final Thoughts

How to Restrict ForeignKey Choices in Django

Introduction

Why Does Django Show All ForeignKey Choices by Default?

When Do You Need to Restrict ForeignKey Choices?

The Magic of the `DefaultRouter`

1. The Multi-Tenancy Shield: `get_queryset()`

2. The Granular Guard: `get_permissions()`

3. The Data Integrity Hook: `perform_create()`

Mastering Django `formfield_for_foreignkey`: Complete Guide with Examples

The Django Way: Using `formfield_for_foreignkey`

1. Using `limit_choices_to` in the Model

Mastering `formfield_for_foreignkey` in Django Admin: A Complete Guide

🔎 What is `formfield_for_foreignkey` in Django Admin?

🔑 When Should You Use `formfield_for_foreignkey`?

What is `db_field`?

Where is `db_field` Used?

Example 3 — Catch-All with `formfield_for_dbfield`

Why is `db_field` Useful?

🔹 What is `_thread_local`?

🛠 Example 4: Class decorator for routes (like Django’s `@admin.register`)

✅ 3. Why C++ Arrays are Declared with `{}` not `[]`