Mam kilka witryn w różnych domenach:example.com, example.org, mail.example.com ipassport.example.org. Wszystkie witryny mają wspólny wygląd i powinny współdzielić tę samą bazę użytkowników.

W takim ekstremalnym przypadku nadal chcę mieć wszystkie stronyprzejrzyście (w miarę możliwości) współdziel sesje użytkowników z następującymi kluczowymi właściwościami:

Pojedyncze logowanie. Gdy użytkownik wpisuje się na stroniepassport.example.org i odwiedza dowolną inną stronę - powinien być traktowany jako zalogowany.

Zalogowani użytkownicy otrzymują „Witaj,$username„Powitanie w nagłówku witryny i innym menu nawigacyjnym, z listą usług, do których mają dostęp. Jeśli nie jest zalogowany, zamiast powitania znajduje się link „Zaloguj się”, wskazującypassport.example.org/signon.

Lista zaufanych domen jest znana, więc jest to dość proste do zaimplementowania albo za pomocą OpenID, albo za pomocą jakiegoś domowego protokołu lekkiego. Gdy użytkownik po raz pierwszy trafi na stronę, przekierowuję go do specjalnego punktu końcowego uwierzytelniania pod adresempassport.example.org, który następnie po cichu przekierowuje go z informacją o tożsamości (lub „nie podpisanej” anonimowej tożsamości). Dla większości przeglądarek jest to całkowicie przezroczyste. Oczywiście używam wartości nonce do zwalczania pętli przekierowań.

Pojedyncze logowanie. Gdy użytkownik kliknie „wyloguj się” w nagłówku dowolnej witryny, gdy następnym razem odwiedza dowolną witrynę - powinien być postrzegany jako „nie wpisujący się”.

OpenID nie był przeznaczony do tego. Moim obecnym pomysłem (mam już częściowo działającą implementację) jest nie wysyłanie tożsamości użytkownika, ale „globalny” token sesji i współdzielenie globalnej tabeli sesji (globalny_sesja_tekstu ↔ relacja użytkownika) w DB.

Obsługa robotów i użytkowników kuchni. Witryny mają obszary publiczne, które powinny być dostępne dla agentów użytkowników bez obsługi plików cookie.

Z tego powodu przekierowanie, o którym wspomniałem w (1), staje się problemem, ponieważ na każde żądanie strony, w końcu wyrzucam agenta użytkownika do autoryzacji punktu końcowego i wstecz. To nie tylko wprowadzi w błąd roboty, ale bardzo szybko zanieczyści moją bazę danych sesji sesjami martwego porodu. I zdecydowanie nie chcę wyświetlać „hej, nie masz włączonych ciasteczek, odejdź!”, Co byłoby bardzo niegrzeczne i rozczarowujące. Chociaż do logowania potrzebuję obsługi plików cookie, chcę, aby użytkownicy bez ograniczeń czytali, do czego służą witryny i tak dalej.

I ja wyraźnienie chcesz umieścić identyfikatory sesji w adresach URL z wyjątkiem niektórych przezroczystych przekierowań między domenami, o których wspomniałem. Uważam, że takie postępowanie jest problemem bezpieczeństwa i ogólnie rzecz biorąc, jest to zła rzecz.

A tu prawie nie mam pomysłów.

Dobra, wiem, że to trudne, ale Google faktycznie robi to w jakiś sposób (google.com, google.lot-gTLD, gmail.com i tak dalej), prawda? To powinno być możliwe.

Byłbym wdzięczny za pomysły dotyczące opisów protokołów (które byłyby najlepsze) lub linki do systemów (albo kod do przeczytania, albo po prostu witryny do oglądania i uczenia się), które już pomyślnie wdrażają coś takiego.

Podsumowując: Kilka domen bez wspólnego roota, wspólna baza użytkowników, pojedyncze logowanie, pojedyncze logowanie, brak plików cookie do przeglądania anonimowego.

Wszystkie witryny są w tej samej sieci (ale spoczywają na różnych serwerach) i częściowo współdzielą tę samą bazę danych PostgreSQL (spoczywając na różnych schematach tej samej bazy danych). Większość stron jest napisana przy użyciu Pythona / Django, ale niektóre z nich używają PHP i Ruby on Rails. Podczas gdy myślę o czymś agnostycznym ramowym i językowym, jestem wdzięczny za wskazanie jakichkolwiek implementacji. Nawet jeśli nie będę w stanie ich używać, jeśli zrozumiem, jak to się robi, może uda mi się wprowadzić coś podobnego.