MVC i konstruktor kontrollera

0

Hej, chcę w aplikacji MVC przechowywać pewne dane o użytkowniku, podczas logowania użytkownika tworzę coś w rodzaju unikalnego identyfikatora sesji który jest mi potrzebny do komunikacji z inną aplikacją. Jak powinienem coś takiego przechować? Na razie trzymam ten obiekt jako pole kontrolera (tylko ten kontroler potrzebuje mieć informację o tym obiekcie), kontroler odpowiedzialny za zarządzaniem użytkownikiem (logowanie, wylogowanie itp.) po zalogowaniu przesyła nazwę użytkownika i identyfikator sesji do tego drugiego kontrolera, ten go sobie zapisuje i jest ok, jednak gdy np. Wykonam RedirectToAction z jednej metody kontrolera na drugą to wywoływany jest konstruktor i pole się zeruje. Jak się w takiej sytuacji zachować?

0

A nie możesz tego tak po prostu trzymać we wbudowanej sesji? Przecież to tylko jedno przypisanie i nie musisz żadnych identyfikatorów generować ani przesyłać. Ładnie by było to tylko opakować w jakąś klasę i wstrzykiwać ją w kontroler, który będzie z tego korzystać. Możesz też serializować/deserializować dane do/z ciastka.

0

Możesz napisać jakiś prosty szyfr tego, np. zmieniający o 3 pozycje w alfabecie/cyfrach do przodu daną literę/cyfrę z tego ID.
Następnie weź, tak jak wspomniał @n0name_l, przechowuj to w sesji.

Jednak z drugiej strony napisałeś:

....podczas logowania użytkownika tworzę coś w rodzaju unikalnego identyfikatora sesji który jest mi potrzebny do komunikacji z inną aplikacją.
.....po zalogowaniu przesyła nazwę użytkownika i identyfikator sesji do tego drugiego kontrolera, ten go sobie zapisuje i jest ok,.....

Tzn co tak naprawdę robi ten drugi kontroler? Po co to zapisuje? Czy korzystasz z bazy danych jakiejś? Jeśli tak to czemu nie zapisywać do nowej tabeli referencji do użytkownika i tego ID sesji, przy wylogowywaniu usuwałbyś ten wpis; w drugiej aplikacji komunikowałbyś się z bazą i pobierał ID sesji na podstawie przesłanego username/user_ID/... a to możesz łatwo dostać w każdym momencie działania aplikacji.

0
ne0 napisał(a):

Możesz napisać jakiś prosty szyfr tego, np. zmieniający o 3 pozycje w alfabecie/cyfrach do przodu daną literę/cyfrę z tego ID.
Następnie weź, tak jak wspomniał @n0name_l, przechowuj to w sesji.

Jednak z drugiej strony napisałeś:

....podczas logowania użytkownika tworzę coś w rodzaju unikalnego identyfikatora sesji który jest mi potrzebny do komunikacji z inną aplikacją.
.....po zalogowaniu przesyła nazwę użytkownika i identyfikator sesji do tego drugiego kontrolera, ten go sobie zapisuje i jest ok,.....

Tzn co tak naprawdę robi ten drugi kontroler? Po co to zapisuje? Czy korzystasz z bazy danych jakiejś? Jeśli tak to czemu nie zapisywać do nowej tabeli referencji do użytkownika i tego ID sesji, przy wylogowywaniu usuwałbyś ten wpis; w drugiej aplikacji komunikowałbyś się z bazą i pobierał ID sesji na podstawie przesłanego username/user_ID/... a to możesz łatwo dostać w każdym momencie działania aplikacji.

Druga aplikacja to taki jakby server, trzyma zalogowanych użytkowników, nadaje im swoją własną sesję i udostępnia im pewne usługi. Po stronie aplikacji webowej użytkownik musi pamiętać ten otrzymany od aplikacji serwerowej klucz sesji. Na tą chwilę przechowuję go najzwyczajniej jako dane sesji (Session["SessionId"] = .... ), ale co jeśli dajmy na to użytkownik nie obsługuje ciasteczek? Dane sesji są zapisywane jako ciasteczka, prawda? Wtedy cała koncepcja padnie.

0
Krwawy Lord napisał(a):

Dane sesji są zapisywane jako ciasteczka, prawda? Wtedy cała koncepcja padnie.

Nie, dane sesji zapisywane są w pamięci serwera albo bazie danych. Ciasteczko jest jedynie jedną z możliwości przechowywania identyfikatora sesji po stronie klienta. W przypadku wyłączenia ciasteczek, identyfikator ten przesłany jest w adresie URL.

0

Co do przesyłania danych w URL, to troche niebezpieczny sposób. W sumie ciasteczka też może ktoś "podwędzić":)

1 użytkowników online, w tym zalogowanych: 0, gości: 1