Django set django session cookie programatically

Question

Я создаю саас, программное обеспечение как сервисный сайт с django.

В соответствии с требованиями проекта пользователи находятся внутри схем/арендаторов, для чего им используется фантастическое приложение django-tenant-schemas, у одного пользователя могут быть учетные записи внутри разных схем (они делят имя пользователя и пароль) ... я хочу, чтобы пользователь переходите через разные схемы, которые они более или менее свободно ... для этого я создал представление, в котором пользователь может выбрать, на какой схеме он хочет быть включенным.

Когда я использую приложение с широким сеансом cookie, когда у меня есть параметр cookie как «.domain.ext» (django documentation), который отлично работает, но это НЕ то поведение, которое мы действительно хотим для нашего приложения.

Нам действительно нужно иметь разные версии приложения на разных вкладках браузера.

Таким образом, мы должны установить конфигурацию файла cookie в «domain.ext», затем все разрывается, потому что исходный вид находится на одном арендаторе, а следующее представление (где только что зарегистрированный пользователь действительно принадлежит) находится внутри другого арендатора, а затем старого cookie удаляется.

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

Или есть альтернативный подход, который мы могли бы использовать для этого? Любые примеры?

EDIT ПРОЯСНИТЬ как потребовано:

Лицо А принадлежит 2 схемы SH1 и SH2 на них обоих он имеет то же имя пользователя и пароль. При каждом изменении пароля хеш пароля реплицируется на всех схемах, к которым они принадлежат, поэтому им не нужно запоминать определенные пароли или имена пользователей.

Когда человек вошел в SH1 URL-адрес будет sh1.domain.com, когда он вошел в SH2 URL-адрес будет sh2.domain.com

Так позволяет сказать, что человек теперь регистрируется на схеме SH1 , он решает переключиться на схему SH2, чтобы иметь возможность сделать это, мне нужно, чтобы пользователь все еще был аутентифицирован, так что вид должен быть в схеме SH1, но затем перенаправлен на новую силу схемы, аутентифицирующую пользователя, но так как cookie (по умолчанию django), когда пользователь приземляется на следующий URL-адрес sh1.domain.com/, несмотря на то, что предыдущий файл cookie удален, и поэтому он должен снова войти в систему, чтобы иметь доступ.

Answer 1

Если я правильно понять, вы хотите, возможность иметь поведение в кросс-доменном печенья, но фактически не с помощью кросс-домен печенья.

Непосредственный ответ, который приходит на ум, «хорошо, используйте куки-файлы с несколькими доменами». Это в значительной степени ванильный пример ситуации, когда вы хотите использовать использование файлов cookie с несколькими доменами. Инженерное решение сложное, чтобы вы могли избежать простого решения, никогда не заканчивается хорошо :-) Если в игре не существует другого ограничения, которое вы не обнаружили, я бы начал с опроса, не стоит ли вам просто делать это легко путь.

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

Единственный способ, которым вы сможете обойти это, - это иметь третью сторону, которая может делиться знаниями. Когда пользователь A регистрируется в SH1, вы выполняете аутентификацию по паролю как обычно, но вы также отправляете флаг где-то, где говорится, что «Пользователь A теперь находится на SH1». Когда A записывается в SH2, вы публикуете соответствующий флаг. Если A возвращается к SH1, вы проверяете центральный источник правды, обнаруживаете, что они в настоящее время находятся на SH2, и принудительно вводит логин.

Возможно, вы могли бы это сделать, манипулируя куки-файлами и сеансовыми ключами, но я подозреваю, что более простой способ - использовать Authentication backend. То, что вы будете писать, - это бэкэйн аутентификации, который очень похож на собственный бэкэнд Django - за исключением того, что он будет проверять статус входа в междоменный домен на центральный источник правды.

Как вы реализуете этот «источник истины» - вам нужен кеш памяти, таблица базы данных или любой другой источник данных. Основная идея заключается в том, что вы не пытаетесь переписать файлы cookie, чтобы один и тот же файл cookie работал на каждом сайте - вы храните файлы cookie каждого сайта независимо, но используя инфраструктуру аутентификации Django, чтобы синхронизировать файлы cookie, когда пользователь перемещается между доменами.