2009-02-17 9 views
6

Mamy kilka aplikacji Django wdrożonych w tej samej poddomenie. Kilka zaawansowanych użytkowników musi przeskakiwać między tymi aplikacjami. Zauważyłem, że za każdym razem, gdy odbijają się między aplikacjami, ich sesyjne ciasteczko otrzymuje nowy identyfikator sesji od Django.Jak uzyskać różne aplikacje Django na tej samej poddomenie, aby udostępnić plik cookie sesji?

Nie używam tabeli sesji Django, z wyjątkiem jednego złożonego przepływu pracy. Jeśli użytkownik odrzuci się między aplikacjami w tym przepływie pracy, straci sesję i będzie musiał zacząć od nowa.

kopany przez kod sesji Django i odkrył, że:

django.conf.settings.SECRET_KEY

służy do wykonywania sprawdzenie integralności sesji na każde żądanie. Jeśli sprawdzenie integralności nie powiedzie się, tworzona jest nowa sesja. Zdając sobie z tego sprawę, zmieniłem tajny klucz w każdej z tych aplikacji, aby używał tej samej wartości, myśląc, że pozwoli to na sprawdzenie integralności i umożliwi im udostępnianie sesji Django. Jednak wydawało się, że nie działa.

Czy istnieje sposób, aby to zrobić? Czy brakuje mi czegoś innego?

Dzięki z góry

Odpowiedz

12

bym zamiast radzę ustawić SESSION_COOKIE_NAME do różne wartości dla dwóch aplikacji. Twoi użytkownicy będą musieli zalogować się dwa razy na początku, ale ich sesje nie będą powodować konfliktów - jeśli zalogują się do aplikacji A, następnie do aplikacji B i powrócą do A, nadal będą mieć sesję A.

Udostępnianie sesji między instancjami Django nie jest prawdopodobnie dobrym pomysłem. Jeśli chcesz pewnego rodzaju jednokrotnego logowania, zajrzyj do czegoś takiego jak django-cas. Będziesz nadal miał 2 sesje (tak jak powinieneś), ale użytkownik zaloguje się tylko raz.

+1

+1: przenoszenie danych uwierzytelniających pomiędzy sesjami Django. –

+0

To dobra sugestia - spróbuję. W przypadku logowania jednokrotnego są to aplikacje wewnętrzne, które są zintegrowane ze starszą aplikacją PHP, która zajmuje się uwierzytelnianiem w sesji PHP, więc nie powinno to stanowić problemu. Naprawdę potrzebuję tylko aplikacji Django, aby nie tupać na każdej innej sesji w tym momencie. Thx –

+0

To załatwiło sprawę.Teraz czuję się trochę głupio, że sam tego nie uważałem :) –

8

Zgadzam się, że sesje udostępniania między instancjami Django prawdopodobnie nie są dobrym pomysłem. Jeśli naprawdę chciał, możesz:

  • upewnij się, że dwie aplikacje Django podziela tą SECRET_KEY
  • upewnij się, że dwie aplikacje Django podziela tą SeSSON_COOKIE_NAME
  • upewnij się, że SESSION_COOKIE_DOMAIN jest ustawiony na coś, pozwala dwóm instancjom udostępniać pliki cookie. (Jeśli naprawdę dzielą tę samą subdomenę, twoje bieżące ustawienie prawdopodobnie jest w porządku.)
  • upewnij się, że obie instancje Django używają tego samego zaplecza sesji (ta sama baza danych, ten sam katalog plików, ta sama konfiguracja memcached, itp.)
  • upewnić się, że cokolwiek umieścić w sesji sens w obu bazach danych Django. przynajmniej, że będzie zawierać identyfikator użytkownika, ponieważ Django auth używa tego, aby pamiętać, który użytkownik jest zalogowany w

wszystko, powiedział, nie próbowałem tego wszystkiego, więc możesz mieć kłopoty!

+0

Zakładając dwie osobne bazy danych/modele, to, jak sądzę, konieczne jest również klonowanie modelu użytkownika w obu projektach i zawsze utrzymywanie ich w synchronizacji. A podczas pobierania instancji użytkownika lub modyfikowania ich, ważne jest, aby ręcznie wybrać tę samą bazę danych (używając = ...). Tabela bazy danych użytkowników zostałaby utworzona w obu projektach, ale tylko jeden byłby faktycznie wypełniony danymi. Po prostu myślę o tym problemie ... Zgodziłbyś się? –

Powiązane problemy