2009-02-17 2 views
6

У нас есть несколько приложений Django, развернутых в одном и том же поддомене. Несколько опытных пользователей должны прыгать между этими приложениями. Я заметил, что каждый раз, когда они отскакивают между приложениями, их cookie сеанса получает новый идентификатор сеанса из Django.Как получить отдельные приложения Django на одном и том же поддомене для совместного использования cookie сеанса?

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

Я вырыл через код сессии Django и обнаружил, что:

django.conf.settings.SECRET_KEY

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

Есть ли способ сделать это? Я что-то пропустил?

Заранее спасибо

ответ

12

Я бы вместо того, чтобы советовать вам установить SESSION_COOKIE_NAME в различных значения для двух приложений. Вашим пользователям все равно придется дважды входить в систему, но их сеансы не будут конфликтовать - если они войдут в приложение A, затем приложение B и вернутся в A, они все равно будут иметь свой сеанс A.

Обмен сеансами между экземплярами Django, вероятно, не очень хорошая идея. Если вы хотите какой-то однократный вход, посмотрите на что-то вроде django-cas. У вас все еще будет 2 сеанса (как и должно быть), но пользователь будет только один раз войти в систему.

+1

+1: перемещение верительных грамот между сессиями Django. –

+0

Это хорошее предложение - я попробую. Для SSO это внутренние приложения, которые интегрированы с устаревшим PHP-приложением, которое обеспечивает аутентификацию в сеансе PHP, поэтому это не должно быть проблемой. Мне просто нужно, чтобы приложения Django не топтались на сеансах друг друга на этом этапе. Thx –

+0

Это сделало трюк.Теперь я чувствую себя немного глупо, что сам себя не считаю :) –

8

Я согласен, что совместные сеансы между экземплярами Django, вероятно, не очень хорошая идея. Если вы действительно хотите, вы можете:

  • убедитесь, что два приложение Джанго один и тот же secret_key
  • убедитесь, что два приложение Джанго один и тот же SeSSON_COOKIE_NAME
  • сделать конечно SESSION_COOKIE_DOMAIN настроено на то, что позволяет двум экземплярам совместно использовать файлы cookie. (Если они действительно разделяют один и тот же поддомен, ваша текущая настройка, вероятно, прекрасна.)
  • убедитесь, что оба экземпляра Django используют один и тот же сеанс (одна и та же база данных, тот же каталог файлов, тот же memcached config и т. Д.)
  • убедитесь, что все положить в сессии имеет смысл в обеих базах данных Django:., по крайней мере, это будет включать в себя идентификатор пользователя, так как Django использует аутентификации, что вспомнить, какой пользователь вошел в систему

Все, что сказал, я на самом деле не пробовал все это, поэтому у вас могут быть проблемы!

+0

Предполагая, что две отдельные базы данных/модели, я думаю, также необходимо клонировать модель пользователя в обоих проектах и ​​всегда держать их в синхронизации. А при получении пользовательских экземпляров или их изменении важно вручную выбрать одну и ту же базу данных (используя = ...). Таблица пользовательских баз данных будет создана в обоих проектах, но только один будет заполнен данными. Просто подумайте о проблеме ... согласитесь ли вы? –