Automatyczne logowanie do bieżącej strony internetowej, jeśli użytkownik jest zalogowany na innej stronie internetowej

Mam około 100 stron internetowych zakodowanych w ASP classic. Każda strona przyjmuje zamówienia i zapisuje je w bazie danych. Jednak płatność tych zamówień musi zostać dokonana na innej stronie internetowej, również zakodowanej w ASP classic. Wszystkie witryny są własnością tej samej firmy, hostowane na tym samym serwerze IIS i korzystają z tej samej bazy danych SQL Server.Automatyczne logowanie do bieżącej strony internetowej, jeśli użytkownik jest zalogowany na innej stronie internetowej

Teraz użytkownik rejestruje się, wprowadzając pewne dane osobowe i logując się na jednej z tych witryn (np. Strona internetowa - na-newjersey.com) i składa zamówienie. Następnie zostaje przekierowany na stronę płatności (payments.master-website.com na https), gdzie niektóre jego dane osobowe (adres, miasto, stan wysyłki, imię i nazwisko posiadacza karty kredytowej itp.) Znajdują się w formularzu płatności. Dane karty kredytowej są wprowadzane na tej stronie.

Ze względu na wrażliwość informacji wyświetlanych na tej stronie, użytkownik musi zalogować się na stronie płatności, zanim będzie mógł przejrzeć wypełniony formularz . I nie chcę, aby użytkownik logował się dwa razy (raz na każdej stronie). Czy istnieje niezawodny sposób sprawdzenia, czy użytkownik jest zalogowany na stronie internetowej , odwołując się do domeny, używając klasycznej ASP.

Krótko mówiąc

Na stronie internetowej BI należy sprawdzić, czy użytkownik jest zalogowany na stronie internetowej
Na stronie internetowej BI potrzebujemy zmiennej sesji ID z witryny
Zarówno strony internetowe używają tego samego serwera bazy danych
Potrzebuję jasnych instrukcji.
Rozwiązanie PHP lub ASP.NET jest dopuszczalne, jeśli jest generyczne/przenośne.

Źródło

2011-12-23 Salman A

dlaczego nie pójdziesz z sugestią Roberta? jest to doskonałe podejście i nie możesz dzielić sesji między różnymi domenami, w przeciwnym razie będziesz w stanie ukraść czyjeś sesje na Facebooku lub coś podobnego. Ilekroć masz zamiar zapłacić, rób tak, jak powiedział Robert. przechowuj losowy ciąg w bazie danych powiązanej z tym użytkownikiem. Zaszyfruj go, przejdź przez protokół SSL do nowej witryny internetowej, odszyfruj go i sprawdź użytkownika w bazie danych. Sprawdź również w czasie (jak w ciągu 1-2 minut po utworzeniu) – Muqito

Słyszałeś o czymś zwanym mostem sesyjnym? – TechGirl

@ Technika: nie, nie. –

Z witryny wywołującej można utworzyć identyfikator lub inną losowo wygenerowaną wartość. Przechowuj go w rekordzie użytkownika (ustawionym na wygaśnięcie w określonym czasie) w bazie danych, zaszyfruj i przekaż go przez SSL do strony płatności, gdzie jest odszyfrowany, a następnie porównany z bazą danych. Jeśli są one zgodne, to użytkownik jest zalogowany, a jeśli nie pasuje, to zostaniesz poproszony o zalogowanie.

Innym sposobem, choć nie jestem pewien, czy można tego dokonać przy użyciu różnych nazw domen, używa się sesji. Ponieważ wszystkie są na tej samej maszynie, może to być możliwe, ale nie jestem na 100% pewny.

Źródło

2011-12-23 14:52:30 Robert

Sesje wygasają po kliknięciu innej nazwy domeny, nawet subdomen. – TheCarver

To działa. Co się stanie, jeśli ktoś skopiuje legalny (i zaszyfrowany) token ze strony internetowej A, otworzy witrynę B w innej przeglądarce/komputerze i opublikuje token (zaszyfrowany)? –

Można użyć niektórych informacji o komputerze/przeglądarce w zaszyfrowanej wartości, która po odszyfrowaniu potwierdzi, że dana osoba nadal znajduje się na tym samym komputerze. Publikacja za pośrednictwem protokołu SSL powinna mieć kolejną warstwę szyfrowania. – Robert

To, o co prosiłeś, nazywa się pojedynczym logowaniem (SSO) i może być realizowane na kilka sposobów. Istnieje wiele tematów na ten temat, na przykład: What's your favorite cross domain cookie sharing approach?, ale wszystkie one różnią się w zależności od indywidualnych wymagań.

W twoim przypadku masz różne domeny (nie możesz w nich współużytkować plików cookie), łączysz http i https (co może być problemem) i masz wiele aplikacji, więc nie wprowadzisz wielu zmian.

Więc polecam do rozważenia propozycję Roberta:

Po uwierzytelnieniu użytkownika po raz pierwszy (strona A) można zaoszczędzić GUID w bazie danych. Dodaj nową tabelę dla sesji z kolumnami dla identyfikatora GUID, identyfikatora użytkownika, adresu IP i znacznika czasu lub zapisz go jako część danych zamówienia. Zapisz identyfikator GUID w obiekcie sesji.
Na stronie, która miała link do strony płatności, ustaw ją w ciągu zapytania lub jako zmienną ukrytą (jeśli jest to formularz).
W drugiej domenie (strona B) sprawdź identyfikator GUID, a następnie wyszukaj go w bazie danych. Jeśli nie był zbyt stary, to uwierzytelnij użytkownika, w przeciwnym razie przekieruj go na stronę logowania.

Jeśli nie możesz zmienić linku do strony płatności, możesz spróbować pominąć krok 2 i zweryfikować użytkownika przez jego adres IP, ale może to być zbyt ryzykowne.

Źródło

2014-06-09 19:51:51 Alex

To wygląda na proste. Co się stanie, jeśli ktoś skopiuje legalny token ze strony A, otworzy witrynę B w innej przeglądarce/komputerze i opublikuje token? –

Powinny to zrobić kombinacja (sprawdzanie adresu IP + check referer + użyj POST). Można również usunąć identyfikator GUID z bazy danych, gdy użytkownik został sprawdzony, więc tego samego identyfikatora GUID (URL) nie można użyć ponownie. – Alex

@SalmanA: nie zapisujesz identyfikatora GUID. Zamiast tego należy zapisać * i zaktualizować * a * losowy UUID * wygenerowany za każdym razem przez witrynę źródłową po przekierowaniu. Następnie usuwasz UUID z DB po otrzymaniu go w witrynie docelowej. Oznacza to, że twój złośliwy użytkownik musiałby * zablokować * swoje własne przekierowanie (w przeciwnym razie UUID zostałby dezaktywowany), ** i ** musi skopiować i opublikować identyfikator GUID z innego komputera w ciągu, powiedzmy, 5 sekund. Normalne przekierowanie 302 nie trwa tak długo, więc wszystkie UUID starsze niż kilka sekund mogą zostać bezpiecznie uznane za nieważne. – LSerni

Uwierzytelnianie oparte na portach to scentralizowana usługa uwierzytelniania świadczona przez firmę Microsoft, która oferuje usługi pojedynczego logowania i profilu podstawowego dla witryn członkowskich. Aby uzyskać więcej informacji, odwiedź następującą witrynę sieci Web firmy Microsoft:

Passport Authentication Provider

Źródło

2014-06-13 08:04:24

Uwierzytelnienie usługi Passport jest przestarzałe i zostało zastąpione przez identyfikator Live ID. Wymagałoby konta Live ID, które różni się od tego, o co tutaj proszono. – Alex

Jeśli nie można wdrożyć Single Sign-On na swoim poziomie infrastruktury, należy użyć Identity Federation która umożliwia zastosowanie innego zaufanego partii podzielić uwierzytelniania poprzez roszczenia.

Można to zrobić za pomocą Security Assertion Markup Language (SAML) bezpośrednio lub z produktami/norm jak:

Ponadto można spojrzeć na OAuth lub OpenID które są więcej wspólnych systemów uwierzytelniania niż SSO lub federacja tożsamości.

Źródło

2014-06-13 16:18:01 JoeBilly

Automatyczne logowanie do bieżącej strony internetowej, jeśli użytkownik jest zalogowany na innej stronie internetowej

Odpowiedz

Powiązane problemy