2017-05-19 48 views
6

Używam aplikacji internetowej, która jest hybrydą MVC 5 + Angular JS. W aplikacji internetowej jest bez uwierzytelniania, a anonimowy użytkownik może poprosić o wycenę niektórych usług. Aby uzyskać cenę, użytkownik musi odpowiedzieć na kilka pytań rozłożonych na kilku stronach. Oto przepływ aplikacji.Używanie HttpCookie do wygaśnięcia limitu czasu/adresu URL

  1. Użytkownik kliknie przycisk, aby uzyskać cenę

  2. Unikalny identyfikator URI żądania jest generowany i użytkownik jest przekierowanie do strony pytania

  3. Użytkownik odpowiada na pytania i użytkownik wysyła odpowiedź. Pytania są podzielone na wiele stron nawigowanych za pomocą routingu kątowego. Odpowiedzi są zapisywane z powrotem do serwera na stronie nawigacji.

  4. Po przesłaniu odpowiedzi przez użytkownika system (serwer) generuje cenę i wyświetla ją użytkownikowi.

Obecnie, jeśli użytkownik zaznaczył URI, może wrócić po kilku dniach i kontynuować od miejsca, w którym wyszedł. Chcę temu zapobiec.

Jakie są różne opcje w MVC? Mogę myśleć o następujących:

  1. HttpCookie Korzystanie z czasem ważności

  2. zaoszczędzić czas ostatniego dostępu w DB i zweryfikować, czy użytkownik ma pochodzić w określonym przedziale czasowym?

Chciałbym uniknąć HttpSession. Jestem skłonny używać HttpCookie, ponieważ wygląda na najprostszą opcję.

  1. Jeśli przyjdzie nam opcja HttpCookie, czy są jakieś skutki uboczne, o których muszę pamiętać?

  2. Czy istnieje inna alternatywa w MVC, której mogę szukać?

+0

Ponieważ nie mają moduł logowania, można również zdecydować się na localStorage który dostanie aktualizowana za każdym razem. – geminiousgoel

+0

Jeśli nie chcesz, aby użytkownik miał dostęp do strony tylko od początku, możesz użyć sessionStorage. gdy użytkownik zamknie okno/kartę, sessionStorage zostanie automatycznie usunięty i można utworzyć użytkownika, aby rozpocząć od początku. – Ashish

+0

Dzięki chłopaki za sugestie, dla mojego scenariusza chciałbym kontrolować to poprzez moją aplikację/serwer MVC. localStorage/sessionStorage są tylko po stronie klienta. –

Odpowiedz

3

W końcu poszedłem z plikiem cookie. Przekłułem unikatowy identyfikator i zapisałem go w ciasteczku z solą. Uważam, że jest to uzasadnione podejście z następujących powodów:

  1. Anonimowa sesja użytkownika będzie krótkotrwała. Raz zamyka przeglądarkę, usuwając plik cookie.

  2. Jeśli użytkownik zakoduje identyfikator URI, szukam pliku cookie sesji w pliku Http Request. Jeśli plik cookie sesji nie zostanie znaleziony, przekierowuję użytkownika na stronę wyzwania.

Poszedłem na algorytm MD5 dla mieszania. Rozumiem, że jest podatna na kolizje, ale jest szybsza niż SHA. Ponieważ nie przechowuję poufnych informacji takich jak hasło w pliku cookie, myślę, że powinno być dobrze.

4

Jeżeli chcesz wygasa jakiś odnośnik bez magazynowania zaangażowanych i usługi muszą być skalowane myślę Wystarczy dodać datę ważności w linku i podpisać.

Wierzę, że można stworzyć swój URL w sposób podobny do tego

pseudokod:

var info = [Payload any info you need to store(questionnaire id or so)] + [expirationDate] 
var sign = HMAC256(info + [SERVER_SECRET]) 
var clientLinkParameter = info + sign 
var clientLink = [baseURL] + [delimiter] + Base64(clientLinkParameter) 

* HMAC256 - to tylko przykład można utworzyć podpis za pomocą dowolnego algorytmu chcesz

Teraz można po prostu sprawdzić link pod kątem ważności, parsując szeregowane dane w części przed ogranicznikiem. Można również sprawdzić, że data nie została zmodyfikowana przez sprawdzenie:

HMAC256([partBeforeDelimiter] + [SERVER_SECRET]) and [partAfterDelimiter] dla równości. Jeśli pasują do tego, jest to łącze wysyłane przez serwer (ponieważ tylko twoje serwery wiedzą, czym jest [SERVER_SECRET]), w przeciwnym razie został zmodyfikowany przez klienta.

Teraz można przechowywać wszelkie nie tajne dane w linku użytkownika pozwalają użytkownikowi udostępnić ten link i innych wspaniałych rzeczy, które można zrobić z linkiem bez obawy, że ktoś zmodyfikować nasz link. Klient może również deserializować pierwszą część, jeśli jest to powszechnie znany algorytm serializacji, taki jak JSON.

myślę, że ten przepływ przyniesie lepsze doświadczenie użytkownika w przypadku nagle zamkniętej przeglądarce (która będzie wyczyścić cookies w Twoim przypadku), a także podział łącza z kimś (jeśli trzeba)

nadzieję, że to pomoże.

+0

To naprawdę przyjemne podejście. Na razie jednak wybrałem plik cookie sesji. Przyjrzę się temu, jeśli będę potrzebował czegoś podobnego w przyszłości. –

3

Wolałbym wygenerować token dla wyjątkowej sesji użytkownika i przechowywać go na serwerze wraz z CreatedDate. W związku z tym adres URL będzie zawierał parametr ciągu zapytań tokenów, który zostanie zweryfikowany względem daty.

  • Jest to bardziej bezpieczne niż opierając się na ciasteczka
  • Pozwala na dodanie Analytics do swojej strony, gdzie można rozpocząć przechowywania Q/kombinacje wraz z generowanymi cen dla danej sesji użytkownika. Zacznij zbierać dane wcześniej. :)