аутентификация веб-приложения dojo - PullRequest
5 голосов
/ 24 октября 2011

Я пытаюсь разработать чистое веб-приложение на javascript с использованием Dojo.Проблема, с которой я сталкиваюсь, заключается в ограничении доступа к частям приложения.Пользователи, прошедшие проверку подлинности, должны иметь доступ ко всему, в то время как пользователи, не прошедшие проверку, должны иметь доступ только к экрану входа в систему.

Проблема в том, что ничто (о чем я знаю) не помешает пользователю открыть браузер.javascript терминал и ввод чего-то вроде: app.displayRestrictedContent(); и, таким образом, получение доступа к экрану, предназначенному для аутентифицированных пользователей.

Я реализовал вход на основе ajax;все вызовы ajax защищены сессией.Таким образом, хотя пользователь, не прошедший проверку подлинности, может загрузить ограниченный экран, он не сможет получить данные для него.Но все же, кажется, что этот экран не может быть произвольно доступным.

Я пытаюсь сделать невозможное?Кажется глупым писать код, такой как if (user.auth) app.displayRestrictedContent();, когда его так легко обойти.И это заставляет меня поверить, что я упускаю что-то довольно очевидное для всех остальных.Я вообще не могу найти много информации о приложениях и моделях аутентификации на основе чистого JavaScript.

Ответы [ 3 ]

2 голосов
/ 24 октября 2011
But still, It seems wrong for this screen to be arbitrarily accessible.

Потому что это код на стороне клиента.Все, что вы пишете в js или компилируете в js, ожидает, что оно будет читабельным для пользователей.

Am I trying to do the impossible?

вы можете динамически загружать js-модули после аутентификации пользователя.Итак, сначала просто загрузите 1 модуль входа.Когда пользователь входит в систему, в случае успеха, сервер возвращает список модулей js для загрузки, если нет, возвращает пустой список.Это также помогает улучшить время загрузки, когда пользователи заходят на ваш сайт.

1 голос
/ 24 октября 2011

Я ни в коем случае не эксперт, но вот некоторые мысли, которые я высказал по этому поводу. Я не думаю, что вы что-то пропустили (если да, то и я тоже) - я думаю, что это довольно фундаментальная проблема со всеми клиентскими приложениями, будь то скомпилированный исполняемый файл или Javascript.

Конечно, скомпилированный исполняемый файл не особенно мешает ему, потому что он превращен в машинный код, который очень сложно прочитать или декомпилировать во что-нибудь полезное. Однако в Javascript приложение часто обслуживается в том виде, в котором вы его написали, поэтому его легко модифицировать и рассуждать.

Это подводит меня к первому полурешению: запутывание вашего Javascript. Если вы используете инструмент сборки Dojo с параметром shrinksafe, все ненужные пробелы удаляются, а все идентификаторы сокращаются, что затрудняет чтение кода. Я назвал это полурешением, некоторые могут сказать, что даже это придает слишком много значения - я сам все еще думаю, что это стоит делать. В конце концов, сокращенный код также загружается быстрее!

Вторая мера, которую я использую в своих приложениях, состоит в том, чтобы разделить разные части на «слои сборки». Например, в моем профиле сборки у меня будет что-то вроде

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
        }
    ]
}

Теперь вместо того, чтобы обслуживать встроенные JS-файлы напрямую в виде статических файлов, я пропускаю запросы через контроллер в моем приложении на стороне сервера, которое проверяет, требует ли уровень JS аутентификации, и зарегистрирован ли пользователь с необходимый доступ.

У этого есть определенные минусы. Файлы JS не кэшируются, и если бы у меня были все мои JS на одном уровне сборки, приложение, вероятно, загрузилось бы немного быстрее. Конечно, есть предел тому, насколько нюансами стоит создавать слои. Больше слоев означает больше хлопот, но и более мелкозернистый доступ к модулю.

Мне было бы интересно услышать, как другие тоже вмешиваются в это. Это хороший вопрос.

1 голос
/ 24 октября 2011

Когда пользователь успешно входит в систему, сервер должен предоставить ему сессионный токен . Впоследствии, когда пользователь запрашивает ресурс (либо просто перенаправляя браузер, либо через AJAX), он показывает серверу свой токен сеанса (либо сохраняя его в cookie-файле и отправляя его автоматически по всем запросам, либо явно передавая его в теле). запроса AJAX)

Сервер может затем использовать токены сеанса от пользователей для управления авторизацией на стороне сервера, отклоняя любой запрос с недействительным или устаревшим токеном.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...