Многопользовательская аренда для приложений, ориентированных на потребителя

Я создаю приложение для потребителей, используя Django и DRF, которое будет иметь учетные записи пользователей. Я хотел бы интегрировать в него мультиарендность, чтобы все данные были разделены по арендаторам (пользователям). Я знаю, что могу просто фильтровать по пользователям в queryset, но мне кажется, что такой подход более безопасен. Мне также известны пакеты django-tenant и django-tenant-schema, но я хотел бы попытаться избежать использования сторонних пакетов, если это возможно.

По сути, там, где есть главная таблица арендаторов, все остальные таблицы имеют посторонний ключ, указывающий на эту таблицу. Правильно ли это звучит?

Так что в основном что-то вроде этого: 

class Tenant(models.Model):
    tenant_id = f'{...}'
    ....


from tenant.models import Tenant
class User(AbstractBaseUser, PermissionsMixin):
    user_id = f'{....}'
    tenant_id = models.ForeignKey(Tenant, ...)
    ...



from tenant.models import Tenant
class Profile(models.Model):
    profile_id = f'{...}'
    user_id = f'{...}'
    tenant_id = models.ForeignKey(Tenant, ...)
    ...

Это действительно один из способов организации многопользовательской сети. django-tenants содержит краткое изложение того, как можно подойти к мультиарендности:

1 - Изолированный подход: Отдельные базы данных. У каждого арендатора своя база данных.
2 - Полуизолированный подход: Общая база данных, отдельные схемы. Одна база данных для всех арендаторов, но одна схема для каждого арендатора.
3 - Общий подход: Общая база данных, общая схема. Все арендаторы используют одну и ту же базу данных и схему. Существует главная таблица арендатора, на которую указывают внешние ключи всех остальных таблиц.

#3 - это тот, о котором вы говорите.

Однако вы сказали вот что:

Я хотел бы интегрировать в него многопользовательскую систему, чтобы все данные были разделены по арендаторам (пользователям). Я знаю, что могу просто фильтровать по пользователям в queryset, но мне кажется, что такой подход более безопасен.

Если вы хотите сказать, что арендатор эквивалентен одному пользователю, то ваш вывод неверен. Внешний ключ, указывающий на User, и внешний ключ, указывающий на Tenant, служат одной и той же цели, и фильтрация данных по арендатору не является (даже немного) более безопасной, чем фильтрация по пользователю - они абсолютно идентичны по форме, функциям и безопасности.

Между двумя следующими вызовами нет никакой разницы с точки зрения безопасности:

customers = Customer.objects.filter(user=user)

customers = Customer.objects.filter(tenant=user.tenant)

Если к одному и тому же арендатору может принадлежать более одного пользователя, то вам может понадобиться таблица Tenant. Но для ясности: это нужно для функции, а не для безопасности.

Если вас беспокоит утечка данных между арендаторами, расширение цепочки внешних ключей ни на что не повлияет (разве что усложнит сопровождение приложения, что, в свою очередь, может усложнить вашу задачу по обеспечению работоспособности).

Вернуться на верх