ExtJS и авторизация страницы (на стороне сервера)

Question

Я ищу информацию о том, как реализовать защищенные страницы с помощью ExtJS 4. По защищенным страницам я имею в виду, что пользователь войдет на наш сайт с помощью Siteminder (SSO), и мы будем иметь личность пользователя. Затем мы определяем, какие роли пользователь мог бы сделать, выполнив вызов базы данных/LDAP и только визуализируя те виды/компоненты, к которым пользователь имеет доступ.

Несколько вопросов приходит на ум:

1.) Конечно, я бы ожидать, мы будем делать проверку полномочий до рендеринга страниц на стороне сервера, так как вы делаете это перед сжиганием Ext. onReady()? Мне нужно, чтобы ExtJS ожидал ответа с сервера?

2.) Каков наилучший способ организовать компоненты страницы, где может быть кто-то, кто-то может видеть конкретный компонент, а другой человек не может?

3.) Как мне предоставить клиенту результирующую страницу (т. Е. Части, к которой пользователь имеет доступ)?

TIA!

Answer 1

1. Используйте технологию на стороне сервера, чтобы предварительно обработать авторизацию, поставив скрипт запуска JS App в JSP/GSP. То, что это делает, заставляет серверные компоненты стороны запускаться сначала, а затем визуализировать HTML/JS/CSS для клиента. Для полного приложения RIA используйте index.gsp (или jsp), и ваш URL-адрес останется «domain/contextroot».

2. Вы можете опросить доступ к ресурсам с помощью ajax-запроса на сервер или, альтернативно, вы можете установить JS-переменные снова с помощью технологии JSP, которая обрабатывается первым до того, как будет возвращена остальная часть ответа клиента.

< г: JavaScript>

//global env var definition 
    var env = "${System.getProperty(Environment.KEY)}"; 

< /g:javascript> 

Оба из них не 100% безопасны, как на стороне клиента код может быть изменен. Реальное обеспечение безопасности должно выполняться на стороне сервера при отправке данных для обработки.

'3. Простым способом было бы скрыть/показать виды и т. Д., Основанные на 2. выше. Также есть некоторые эксперименты с модуляцией приложения MVC на стороне клиента с помощью ленивых (вручную) инициализирующих контроллеров, которые могут потребоваться или не понадобиться.

Надеюсь, это поможет.

DB :)

Answer 2

1. чек из Role-based access control. Я использую RBI на базе баз данных Yii и имею php-скрипт, который возвращает правила rbac в json-формате, когда ext запускает

2. на клиенте, лучше всего просто скрыть или отключить функциональность, которая не разрешена.

3. на сервере, вы должны выбросить 403 http error, если пользователю не разрешено выполнять какую-либо функцию. обрабатывать исключения ajax в ext и проверять на 403s.

Answer 3

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

Для начала аутентификация пользователя выполняется без использования extjs с использованием простой страницы HTML/CSS. После входа пользователя в систему его данные (идентификатор пользователя, роль) сохраняются в сеансе PHP. Затем страница перенаправляется в одно из двух приложений extjs.

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

Оба приложения имеют свои классы, наследуемые от базовых классов. Итак, у нас есть, например, base.mainMenu, из которых наследуются и admin.mainMenu, и clients.mainMenu. Единственное отличие в скрипте app.js заключается в том, что загруженные контроллеры и в динамическом модуле загрузки extJS 4 загружаются только связанные представления (то есть, на стороне клиента). В моем случае все страницы загружаются динамически в любом случае, поэтому мои пользователи могут динамически загружать страницы в своем основном меню.

Приложение администратора блокирует определенные функции, используя глобальную переменную JS, которая включает в себя роль пользователя. Так, например, скрытие кнопки «edit» от модераторов (группа администраторов с меньшими правами) выполняется после загрузки представления (на практике это фактически выполняется, не загружая плагин, который позволяет редактировать на представлении).

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

Итак, у вас есть 3 различных стратегий, которые вы можете смешивать и матч:

• Загрузка различных приложений для различных пользователей. Если ваши классы все присущи базовым классам, это проще, чем поддерживать 2 или более совершенно разных приложения.
• Использование глобальной переменной JS для отключения/включения определенных функций для определенных пользователей. Это полезно только в том случае, если у вас нет проблем с функциями загрузки на стороне клиента, которые затем отключены (но все еще видны отладчиками).
• Независимо от всего, все вызовы на стороне сервера проверяются на переменную сеанса.

Answer 4

Если вы работаете на фоне Java и удобно используете Spring, я написал подход с использованием Spring Security here. Это позволит вам подключить любой механизм аутентификации, который вы хотите. Основное отличие состоит в том, что вместо использования index.html для загрузки приложения я имею JSP, чтобы фильтр Spring Servlet срабатывал для аутентификации. Приложение Ext JS блокируется до тех пор, пока пользователь не будет аутентифицирован и не будут предоставлены роли/разрешения пользователя.