Как обрабатывать аутентификацию и AUTH_USER_MODEL в мультитенантном Django с отдельными схемами в PostgreSQL?

Я разрабатываю мультитенантное SaaS-приложение с использованием Django, где у каждого клиента есть своя отдельная база данных со своей собственной схемой и связями. Однако я пытаюсь понять, как правильно управлять аутентификацией и определять AUTH_USER_MODEL в этой среде.


📌 Системные требования

  1. Глобальные суперадминистраторы, которые управляют системой и хранятся в общедоступной базе данных (public).
  2. Пользователи-арендаторы, которые существуют в своих соответствующих базах данных и имеют связи с другими таблицами в своей собственной базе данных.
  3. Отдельная аутентификация: Суперадмины должны проходить аутентификацию в общедоступной базе данных. Пользователи-арендаторы должны проходить аутентификацию в своей конкретной базе данных клиентов.

Основная проблема заключается в том, что Django допускает только одну AUTH_USER_MODEL, но мне нужно управлять пользователями отдельно для каждого клиента, сохраняя при этом возможность связывать их с другими таблицами в их соответствующих базах данных.


❌ Текущая проблема

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

Я попытался определить две разные пользовательские модели, но Django не допускает множественную AUTH_USER_MODEL, что усложняет аутентификацию.


✅ Возможное решение

Я подумал о том, чтобы определить базовую модель BaseUser, которая расширяет AbstractUser, а затем создать две унаследованные модели.


Но я не уверен, какой из них правильный, есть другой?.

Я изучал, как обрабатывать аутентификацию в мультитенантных системах с Django и PostgreSQL, и проконсультировался с ChatGPT. Он предположил, что стандартной практикой является:

  1. Централизованная пользовательская модель: Используйте однопользовательскую модель в схеме public для централизации аутентификации. PostgreSQL поддерживает взаимосвязи между схемами.

  2. арендатор отношения: каждого пользователя public связано с конкретным арендатором через идентификатор или внешнего ключа, что делает пользователей легче управление и обеспечение сведения изоляции.

  3. Проверка токенов: Токены JWT управляются централизованно и содержат информацию о клиенте, обеспечивая безопасность данных и доступ только к соответствующему клиенту.

В качестве сопровождающего Django-арендаторов. Я бы порекомендовал вам использовать Django-Tenant-users.

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