基于Django&DRF的面向消费者应用多租户（按用户数据隔离）方案可行性咨询

Hey there! Let's break down your approach to multi-tenancy in Django/DRF for user-isolated data.

First off: your core idea is totally feasible. The pattern you're describing—having a central Tenant table with all other business tables linking to it via a foreign key—falls into the shared database, shared schema multi-tenancy model, which is a great fit for consumer-facing apps where each user acts as a tenant. It’s definitely more secure than just adding manual filters to querysets, since it enforces isolation at the data model level.

A quick note on your model code examples #

Your skeleton makes sense, but there are a couple of tweaks to make it cleaner and avoid pitfalls:

• Django automatically generates an id primary key for every model, so you don’t need to explicitly define tenant_id, user_id, or profile_id unless you have a specific reason (like using a UUID instead of an integer). Stick with the default id to keep things simple.
• The Profile model doesn’t need a direct tenant_id foreign key. Since Profile already links to User, and User links to Tenant, you can access the tenant via profile.user.tenant. Adding a duplicate tenant field creates data redundancy and risks inconsistencies (e.g., a profile’s tenant not matching its user’s tenant).

Here’s a revised version of your models:

# tenant/models.py
from django.db import models

class Tenant(models.Model):
    # Add any tenant-specific fields here, like name or subscription tier
    name = models.CharField(max_length=255)

# users/models.py
from django.contrib.auth.models import AbstractBaseUser, PermissionsMixin
from django.db import models
from tenant.models import Tenant

class User(AbstractBaseUser, PermissionsMixin):
    email = models.EmailField(unique=True)
    tenant = models.ForeignKey(Tenant, on_delete=models.CASCADE, related_name="users")
    # Add other user fields (username, etc.) as needed

# profiles/models.py
from django.db import models
from users.models import User

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE, related_name="profile")
    bio = models.TextField(blank=True)
    # No need for a direct tenant foreign key here

Key implementation considerations to keep things secure and scalable #

1. Auto-filter queries by tenant
   Don’t rely on manual filter(tenant=...) calls—they’re easy to forget, which leads to data leaks. Instead, create a custom manager/queryset that automatically filters results for the current tenant:

   # core/managers.py
   import threading
   from django.db import models
   from django.http import HttpRequest
   
   # Use thread-local storage to access the current request/tenant (set via middleware)
   _request_local = threading.local()
   
   def get_current_request() -> HttpRequest | None:
       return getattr(_request_local, 'request', None)
   
   class TenantQuerySet(models.QuerySet):
       def for_current_tenant(self):
           request = get_current_request()
           if not request or not hasattr(request.user, 'tenant'):
               return self.none()
           return self.filter(tenant=request.user.tenant)
   
   class TenantManager(models.Manager):
       def get_queryset(self):
           return TenantQuerySet(self.model, using=self._db).for_current_tenant()
   

   Then use this manager in all your tenant-linked models:

   from core.managers import TenantManager
   
   class Profile(models.Model):
       # ... fields ...
       objects = TenantManager()
   

   You’ll also need a middleware to store the current request in thread-local storage:

   # core/middleware.py
   class TenantRequestMiddleware:
       def __init__(self, get_response):
           self.get_response = get_response
   
       def __call__(self, request):
           _request_local.request = request
           response = self.get_response(request)
           del _request_local.request
           return response
   

   Don’t forget to add this middleware to your settings.MIDDLEWARE list.

2. Enforce tenant-level permissions in DRF
   Add a custom permission class to ensure users can only access resources belonging to their tenant:

   # core/permissions.py
   from rest_framework.permissions import BasePermission
   
   class IsTenantMember(BasePermission):
       def has_object_permission(self, request, view, obj):
           # Check if the object's tenant matches the user's tenant
           return obj.tenant == request.user.tenant
   
       def has_permission(self, request, view):
           # Ensure authenticated users belong to a tenant
           return super().has_permission(request, view) and hasattr(request.user, 'tenant')
   

   Use this permission in your DRF views:

   from rest_framework.viewsets import ModelViewSet
   from core.permissions import IsTenantMember
   from profiles.serializers import ProfileSerializer
   from profiles.models import Profile
   
   class ProfileViewSet(ModelViewSet):
       serializer_class = ProfileSerializer
       permission_classes = [IsTenantMember]
       queryset = Profile.objects.all()
   

3. Handle tenant creation automatically
   When a user signs up, create a corresponding Tenant record automatically (since each user is a tenant in your case):

   # users/signals.py
   from django.db.models.signals import post_save
   from django.dispatch import receiver
   from users.models import User
   from tenant.models import Tenant
   
   @receiver(post_save, sender=User)
   def create_tenant_for_new_user(sender, instance, created, **kwargs):
       if created:
           Tenant.objects.create(name=instance.email, users=instance)
   

   Don’t forget to register this signal in your app’s apps.py:

   # users/apps.py
   from django.apps import AppConfig
   
   class UsersConfig(AppConfig):
       default_auto_field = 'django.db.models.BigAutoField'
       name = 'users'
   
       def ready(self):
           import users.signals
   

Pros and cons of this approach #

Pros

• No third-party dependencies: Uses only Django/DRF’s native tools, so you avoid the overhead of maintaining external packages.
• Simple database structure: Easy to migrate, query, and debug—perfect for small to mid-sized consumer apps.
• Model-level isolation: Harder to accidentally expose cross-tenant data compared to manual query filtering.

Cons

• Performance at scale: As your user base grows, tables will get large. Make sure to add indexes on the tenant field to keep queries fast.
• No physical data isolation: All tenants share the same tables, which might not meet strict compliance requirements (e.g., healthcare data that needs physical separation).
• Cross-tenant operations: Bulk actions or analytics across tenants will be slower and more complex than in a schema-isolated setup.

Overall, your approach is solid and well-suited for a consumer-facing app where each user is a tenant. With the tweaks above, you’ll have a secure, maintainable multi-tenancy setup without relying on external packages.

备注：内容来源于stack exchange，提问作者user3125823