Основы django-арендаторов: SHARED_APPS vs TENANT_APPS
Я использую django-tenants для многопользовательского приложения.
В docs говорится о настройке SHARED_APPS и TENANT_APPS.
SHARED_APPS - это кортеж строк, такой же как INSTALLED_APPS, и должен содержать содержать все приложения, которые вы хотите синхронизировать с public
.
Если я хочу, чтобы приложение (например, django.contrib.auth) было доступно и в публичной схеме, и в общей схеме, нужно ли мне включить его только в SHARED_APPS или мне нужно включить его и в SHARED_APPS, и в TENANT_APPS?
"SHARED" подразумевает, что все в этом списке доступно через всех арендаторов и публичную схему, но документация, похоже, подразумевает обратное?
При использовании django-арендаторов ваша база данных будет содержать схему public (т.е. каталог), и схему для каждого арендатора, скажем tenant1, tenant2, ...
Данные моделей, принадлежащих к SHARED_APPS, окажутся в общей папке и будут доступны всем остальным арендаторам (схемам). Следовательно, достаточно только один раз включить int в SHARED_APPS
Я являюсь сопровождающим Django Tenants. Если вы хотите, чтобы один и тот же пользователь мог получить доступ и в shared, и в tenant, вы должны поместить его только в SHARED_APPS. Однако это будет означать, что один и тот же пользователь сможет получить доступ к нескольким арендаторам. Я думаю, вы не захотите этого, если не напишете таблицу разрешений. Это также означает, что ваши пользователи не являются арендаторами.
Если вам нужны разные пользователи, вы можете разместить их как в SHARED_APPS, так и в TENANT_APPS. Django Tenant всегда сначала запрашивает локальную схему/арендатора, и если таблица не существует, он обращается к публичной схеме. Именно так я делаю это в своем проекте. Обратите внимание, что вам нужно убедиться, что django.contrib.sessions в обоих приложениях SHARED & TENANT, иначе вы получите проблему безопасности при переходе от одного арендатора к другому.
Другая мысль, на которую следует обратить внимание - https://github.com/Corvia/django-tenant-users