2016-07-13 15 views
5

Jestem w sytuacji, w której strona, nad którą pracuję, menedżer chce zezwolić użytkownikowi na zalogowanie się i nie martwić, jeśli zalogował się za pośrednictwem protokołu http lub https. Na podstawie innego pytania SO (how can I share an asp.net session between http and https) myślałem, że będzie to możliwe, jeśli ustawię secure = false na cookie. Aby dodać do tego, używamy poddomeny do bezpiecznej części strony. W przypadku http używamy witryny site.com, a https korzysta z witryny secure.site.com. Próbowałem więc ustawić domenę do uwierzytelniania w web.config.Udostępnianie uwierzytelniania w trybie Secure and Nonsecure

<authentication mode="Forms"> 
    <forms loginUrl="/account/login" 
    protection="All" timeout="30" name=".ASPXAUTH" path="/" 
    requireSSL="false" slidingExpiration="true" defaultUrl="/" 
    cookieless="UseDeviceProfile" domain="site.com" 
    enableCrossAppRedirects="false" /> 
</authentication> 

Czy robię to wszystko źle? Rozumiem, że są pewne obawy związane z bezpieczeństwem i zamierzałem zwrócić się do nich po złożeniu wniosku. Po prostu chcę zezwolić użytkownikowi na zalogowanie się raz i zapamiętanie przez http i https. Dzięki.

+3

Wystarczy przekierować wszystko do https, problem rozwiązany. – mxmissile

+0

czułem się tak samo, ale kierownik nie chce go w ten sposób. – Wade73

+1

Brzmi jak sytuacja na [ powiedz nie] (https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/saying-no). Nasza branża uważa, że ​​dzielenie się ruchem między bezpiecznymi i niebezpiecznymi kanałami jest złe, dlatego stara się sprawiają, że jest to niemożliwe, a przynajmniej trudne nstinct mówi: "po prostu używaj bezpiecznego kanału do wszystkiego." To byłoby nieprofesjonalne, gdybyś poświęcił cenny czas na budowanie pracy nad najlepszymi praktykami. – Will

Odpowiedz

2

Myślę, że masz błędną domenę w swoim pliku web.config. Należy go zmienić na

domain=".site.com" 

Więc pozwalając formularze auth cookies żyć zarówno na ssl.site.com i no-ssl.site.com domeny na przykład.

Wszystko to oznacza, że ​​każdy rodzaj zabezpieczeń zaczyna się od https: // w przypadku wszystkich rozwiązań - w przeciwnym razie możesz przejść do ataków typu "man-in-the-middle" (serwer proxy sieci Web może wstrzyknąć nieodpowiednie treści do Twojego rozwiązania, mogą one wykraść cookies autoryzacji & używać go w strumieniu na https://ssl.site.com itp

+0

Użyłem obu .site.com i site.com, ponieważ oba pokazują w przykładach, które widziałem, ale bez powodzenia. Wygląda na to, że nie rozpoznaje cookie auth po ustawieniu domeny na cookie. – Wade73

Powiązane problemy