Próbuję opracować czystą aplikację WWW JavaScript za pomocą Dojo. Problemem, na którym stoję, jest jednym z ograniczenia dostępu do części aplikacji. Uwierzytelniani użytkownicy powinni mieć dostęp do wszystkiego, podczas gdy nie uwierzytelniani użytkownicy powinni mieć dostęp tylko do ekranu logowania.

Problem polega na tym, że nic (że jestem świadomy), zatrzyma użytkownika od otwarcia terminalu JavaScriptowego przeglądarki i wprowadzenie czegoś takiego jak: app.displayRestrictedContent();, a tym samym zdobywanie dostępu do ekranu przeznaczonego dla uwierzytelnionych użytkowników.

Wdrożyłem login oparty na AJAX; Wszystkie połączenia AJAX są zabezpieczone sesją. Więc gdy nie uwierzytelniony użytkownik może załadować ekran ograniczony, nie będą mogli pobrać dane dla niego. Ale wciąż wydaje się, że ten ekran jest arbitralnie dostępny.

Czy próbuję zrobić niemożliwe? Wydaje się głupie do pisania kodu, takiego jak if (user.auth) app.displayRestrictedContent();, gdy jest tak łatwo obejść. I to prowadzi mnie do wierzenia, że tęsknię za czymś raczej oczywistym dla wszystkich innych. Nie mogę znaleźć wiele informacji na wszystkich aplikacjach opartych na JavaScript i modelach uwierzytelniania.

5
andreb 24 październik 2011, 08:26

3 odpowiedzi

Najlepsza odpowiedź

W żadnym wypadku nie jestem ekspertem, ale tutaj są myślami o tym, że zrobiłem to. Nie sądzę, żebyś coś przegapił (jeśli tak, mam też) - myślę, że jest to dość fundamentalna kwestia ze wszystkimi aplikacjami klienckimi, niezależnie od tego, czy jest to skompilowany wykonywanie lub javascript.

Oczywiście skompilowany wykonywalny wykonywalny nie jest szczególnie utrudniony przez niego, ponieważ został wykonany w kodzie maszynowym, który jest bardzo trudny do odczytania lub dekompilowania w cokolwiek przydatny. Jednak z JavaScript aplikacja jest często obsługiwana dokładnie tak, jak to napisałeś, a więc łatwo jest modyfikować i rozumować.

To przynosi mnie do pierwszego pół-roztworu: zaciemniając JavaScript. Jeśli używasz narzędzia budowy Dojo z parametrem Shrinksafe, wszystkie niepotrzebne białe znaki są usuwane, a wszystkie identyfikatory są skrócone, dzięki czemu kod jest dość trudny do odczytania. Nazwałem to półautorem, niektórzy mogą powiedzieć nawet, że daje to za dużo kredytu - ja nadal myślę, że warto robić. W końcu również skurczony kod jest szybszy!

Druga miara, którą biorę, w moich aplikacjach jest oddzielenie różnych części do "warstw budowy". Na przykład, w moim profilu budowania, będę miał 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 serwować wbudowane pliki JS bezpośrednio jako pliki statyczne, pozwalam prośbom przejść przez kontrolera w mojej aplikacji po stronie serwera, co sprawdza, czy warstwa JS wymaga uwierzytelnienia i czy użytkownik jest zalogowany z niezbędnym dostępem .

Ma to pewne zalety. Pliki JS nie są buforowane, a jeśli miałem wszystkich JS w jednej warstwie budowlanej, aplikacja prawdopodobnie ładuje się nieco szybciej. Oczywiście ma oczywiście limit, jak nie jest wart warstwy. Więcej warstw oznacza więcej kłopotów, ale także bardziej drobno ziarnisty dostęp do modułu.

Byłbym zainteresowany, aby usłyszeć inni w tym gimnazjum. To dobre pytanie.

1
Frode 24 październik 2011, 13:18
But still, It seems wrong for this screen to be arbitrarily accessible.

Ponieważ jest kodem po stronie klienta. Wszystko, co piszesz w JS lub skompilowany do JS, spodziewaj się, że będzie czytelny przez użytkowników.

Am I trying to do the impossible?

Możesz dynamicznie ładować moduły JS po uwierzytelniach użytkownika. Początkowo po raz pierwszy załaduj 1 moduł logowania. Gdy użytkownik loguje się, jeśli zostanie udany, serwer zwróci listę modułów JS, aby załadować, jeśli nie, zwróć pustą listę. Pomaga również poprawić czas ładowania, gdy użytkownicy przychodzą na Twoją stronę.

2
Anh Pham 24 październik 2011, 19:00

Gdy użytkownik z powodzeniem loguje serwer powinien zapewnić mu token sesji . Następnie, gdy użytkownik żąda zasobu (albo przez tylko przekierowanie przeglądarki lub przez AJAX) pokazuje serwer jego token sesji (albo przez przechowywanie go w pliku cookie i wysyłając go automatycznie na wszystkich żądaniach lub wyraźnie przekazując go w organizmie żądania ajax)

Serwer może następnie używać żetonów sesji od użytkowników do kontroli autoryzacji serwera serwera, odrzucając dowolne żądanie z nieprawidłowym lub przestarzałym tokenem.

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

1
hugomg 24 październik 2011, 12:45