Zarządzanie danymi sesji internetowej/przepływem kontrolera dla wielu kart

Question

Mam aplikację internetową Java, która przechowuje pewne dane w sesji. Dane w sesji zmieniają się, gdy użytkownik wchodzi w interakcję z aplikacją (np. Przepływ jest zarządzany przez kontroler, każdy kontroler ma kilka stron formularzy, na każdej stronie formularza niektóre dane są aktualizowane w sesji, a przepływ przechodzi do strony następnego formularza).

Problem polega na tym, że niektórzy użytkownicy otwierają do aplikacji więcej niż jedną zakładkę, a każda karta zawiera inny krok w przepływie. W tym momencie dane w sesji są pomieszane, ponieważ zakładki mają tę samą sesję (aplikacja używa sesji zarządzanych przez ciasteczka).

Nakłanianie użytkowników do korzystania z różnych przeglądarek w celu uniknięcia udostępniania tego samego identyfikatora sesji (np. Jedno okno przeglądarki Firefox i jedno okno przeglądarki Internet Explorer) nie wchodzi w grę, ponieważ w pewnym momencie ktoś o tym zapomni i zamiast tego użyje kart, a tym samym zepsuje do ich danych.

Dodanie pewnych weryfikacji, które wykrywają, że inny przepływ jest żądany z innej zakładki i wyświetla komunikat użytkownikowi mówiącemu, że to niedozwolone, również nie jest opcją, ponieważ wkurza użytkowników, a my tego nie chcemy? : D

Faktem jest, że korzystanie z innej karty jest przydatne dla użytkowników, ponieważ są bardziej wydajni w używaniu aplikacji, więc zachowuję tę opcję. Ale teraz pytanie brzmi: jak najlepiej zarządzać danymi jednej sesji dla więcej kart?

Pomyślałem, że kontroler wygeneruje token, gdy rozpocznie przepływ i przekaże ten token do każdej strony formularza, która z kolei odeśle ją do siebie. Jeśli inna karta zażąda tego samego działania kontrolera, gdy trwa ciągły przepływ, należy wygenerować kolejny token i przekazać go dookoła.

Zasadniczo chcę, aby każdy przepływ miał token iw sesji nie będę przechowywać tylko jednego zestawu danych, ale będę mieć zestaw danych dla każdego tokena, a następnie dopasowywać żądania na podstawie tokena.

Problem polega na tym, że takie podejście będzie wymagało wielu poprawek do aplikacji i zastanawiałem się, czy istnieje najlepsza praktyka w zarządzaniu taką sytuacją lub czy ktoś może zaproponować inne podejście. Jestem otwarty na pomysły.

Czy spotkałeś się z taką sytuacją? Jak sobie z tym poradziłeś?

Answer 1

Zwykle robi się to poprzez przypisanie windowId do każdej karty/okna i przekazywanie go do każdego żądania. Jsf obsługuje to przez orchestra. Spring mvc będzie obsługiwać go w następnej wersji.

Niedawno potrzebowałem tego w prostym przypadku, więc sam go wdrożyłem. Zajęło pół godziny. Jednak mój zakres był bardzo ograniczony:

• zdać windowId z każdego żądania, i odesłać go z powrotem do kolejnego wniosku. Za pierwszym razem - wygeneruj.
• dla każdego atrybutu, który chcesz zapisać w sesji, umieścić Map<String, Object> gdzie kluczem jest windowId

Answer 2

To jest dokładnie to, co Seam został stworzony, aby obsłużyć. W Seam istnieje pojęcie o nazwie Conversation, które w zasadzie robi dokładnie to, co wyjaśniasz. Zasadniczo konwersacje są sposobem na podzielenie sesji na wiele części, które mogą wygasnąć po pewnym czasie. Możesz spojrzeć na kod źródłowy dla org.jboss.seam.core.Klasa menedżerów, aby zobaczyć, jak jest ona faktycznie zaimplementowana i uzyskać inspirację;)

Answer 3

W zależności od złożoności aplikacji, możesz zbadać implementację zakładek w swojej aplikacji. Zapewnia to hurtową kontrolę nad przepływem, a jednocześnie zapewnia użytkownikom odpowiednią funkcjonalność. Twierdzę, że to najbezpieczniejsze rozwiązanie, ponieważ nie będziesz miał zależności od sposobu, w jaki przeglądarka obsługuje sesje, minimalizując liczbę "znanych niewiadomych".

Oczywiście, będzie to potencjalnie duży koszt początkowy, w zależności od struktury aplikacji. Bez dodatkowych informacji o aplikacji jesteś najlepszą osobą do podjęcia decyzji.

Answer 4

Można także spróbować owinąć aplikacji wewnątrz Adobe Air

A potem ograniczyć swoją aplikację internetową, aby być tylko accessable od tego powietrza. Robiąc to, nie musisz rozważać fragmentacji przeglądarki internetowej i jej unikalnego zachowania.