uwierzytelnianie aplikacji sieciowej dojo

Question

Próbuję opracować czystą aplikację internetową javascript, używając Dojo. Problem, który napotykam, polega na ograniczeniu dostępu do części aplikacji. Uwierzytelnieni użytkownicy powinni mieć dostęp do wszystkiego, podczas gdy nieuwierzytelnieni użytkownicy powinni mieć dostęp tylko do ekranu logowania.

Problem polega na tym, że nic (o czym mi wiadomo) powstrzyma użytkownika przed otwarciem terminalu javascript przeglądarki i wprowadzeniem czegoś takiego jak: app.displayRestrictedContent();, a tym samym uzyskania dostępu do ekranu przeznaczonego dla uwierzytelnionych użytkowników.

Zaimplementowałem logowanie oparte na ajaxu; wszystkie wywołania ajax są zabezpieczone sesją. Tak więc, podczas gdy nieuwierzytelniony użytkownik może załadować ograniczony ekran, nie będzie mógł pobrać dla niego danych. Ale nadal wydaje się, że ten ekran jest niewłaściwy.

Czy próbuję zrobić niemożliwe? Wydaje się głupio pisać kod, taki jak if (user.auth) app.displayRestrictedContent();, gdy tak łatwo go ominąć. A to prowadzi mnie do przekonania, że ​​brakuje mi czegoś oczywistego dla wszystkich innych. Nie mogę znaleźć wiele informacji na temat czystych aplikacji opartych na javascript i modeli uwierzytelniania.

Answer 1

jestem bynajmniej ekspertem, ale oto kilka myśli zrobiłem w tej sprawie. Nie wydaje mi się, żebyś coś przeoczył (jeśli tak, ja też) - myślę, że jest to dość zasadniczy problem dla wszystkich aplikacji klienckich, niezależnie od tego, czy jest to skompilowany plik wykonywalny czy JavaScript.

Oczywiście skompilowany plik wykonywalny nie jest przez niego szczególnie utrudniony, ponieważ został przekształcony w kod maszynowy, który jest bardzo trudny do odczytania lub dekompilacji w coś użytecznego. W JavaScript jednak aplikacja jest często serwowana dokładnie tak, jak ją napisałeś, więc łatwo ją modyfikować i uzasadnić.

To prowadzi mnie do pierwszego pół-rozwiązania: zaciemnianie kodu Javascript. Jeśli użyjesz narzędzia budowania Dojo z parametrem shrinksafe, wszystkie niepotrzebne białe znaki zostaną usunięte, a wszystkie identyfikatory skrócone, co utrudni odczytanie kodu. Nazwałem to pół-rozwiązaniem, niektórzy mogą nawet powiedzieć, że daje to zbyt dużo kredytów - ja sam nadal uważam, że warto to robić. W końcu skurczony kod również jest szybszy!

Drugą miarą, którą robię w moich aplikacjach, jest rozdzielenie różnych części na "warstwy kompilacji". Na przykład, w moim profilu kompilacji, będę musiał coś takiego

dependencies = { 
    .. 
    layers: [ 
     { name: "../myApp/Core.js", resourceName: "myApp.Core", 
      dependencies: ["myApp.Core", "myApp.Foobar"] 
     }, 
     { name: "../myApp/modules/Login.js", resourceName: "myApp.modules.Login", 
      dependencies: ["myApp.modules.Login", "myApp.modules.LoginUi"...], 
      layerDependencies: ["../myApp/Core.js"] 
     }, 
     { name: "../myApp/modules/Secret.js", resourceName: "myApp.modules.Secret", 
      dependencies: ["myApp.modules.Secret", "myApp.modules.SecretUi"], 
      layerDependencies: ["../myApp/Core.js"], 
      authentication: 42 
     } 
    ] 
} 

Teraz, zamiast służyć wbudowane pliki JS jako pliki statyczne, pozwoliłem wnioski przechodzą przez kontrolera w mojej aplikacji po stronie serwera, który sprawdza, czy warstwa JS wymaga uwierzytelnienia i czy użytkownik jest zalogowany z niezbędnym dostępem.

To ma pewne minusy. Pliki JS nie są buforowane, a gdybym miał wszystkie moje JS w jednej warstwie kompilacji, aplikacja prawdopodobnie ładowałaby się nieco szybciej.Oczywiście istnieje również granica tego, jak niuansów warto tworzyć warstwy. Więcej warstw oznacza więcej kłopotów, ale także bardziej precyzyjny dostęp do modułów.

Chciałbym również usłyszeć, jak inni dzwonią w tej sprawie. To dobre pytanie.

Answer 2

Po pomyślnym zalogowaniu się użytkownika serwer powinien dostarczyć mu token sesji . Następnie, za każdym razem, gdy użytkownik poprosi o zasób (albo przez przekierowanie przeglądarki, albo poprzez AJAX), pokazuje serwerowi swój token sesji (albo zapisując go w ciasteczku i wysyłając go automatycznie na wszystkie prośby, albo wyraźnie przekazując go w treści żądania AJAX)

Serwer może wtedy używać tokenów sesji od użytkowników do kontrolowania autoryzacji po stronie serwera, odrzucając każde żądanie z nieważnym lub nieaktualnym tokenem.

https://en.wikipedia.org/wiki/HTTP_cookie#Session_management

Answer 3

But still, It seems wrong for this screen to be arbitrarily accessible. 

Ponieważ jest to kod po stronie klienta. Cokolwiek napiszesz w js lub skompilujesz do js, ​​spodziewasz się, że będzie ono czytelne dla użytkowników.

Am I trying to do the impossible? 

można dynamicznie ładować moduły js po uwierzytelnieniu użytkownika. Najpierw wystarczy załadować 1 moduł logowania. Gdy użytkownik zaloguje się, jeśli się powiedzie, serwer zwróci listę modułów js do załadowania, jeśli nie, zwróci pustą listę. Pomaga także poprawić czas ładowania, gdy użytkownicy odwiedzają Twoją witrynę.