Подтвердить что ты не робот

Лучший способ скрыть/отключить элементы GUI на основе прав пользователя?

Я запускаю веб-приложение с клиентской стороной, реализованное в чистом ExtJS и среднем уровне в Grails. Приложение имеет авторизацию на основе ролей, в которой пользователь может иметь множество мелкозернистых ролей, таких как SOME_FORM_READ, SOME_FORM_UPDATE, SOME_DATA_DELETE, SOME_DATA_READ и т.д. Основываясь на ролях пользователя, некоторые элементы GUI должны быть отключены или скрыты, в то время как другие должны быть в режиме только для чтения.

Я сделал поиск в Интернете, но не нашел шаблона дизайна, который специально решает эту проблему, поэтому я придумал свой собственный дизайн. Я уверен, что многие веб-приложения там будут иметь аналогичное требование, поэтому я хотел бы опубликовать свой проект здесь и услышать мнение людей об этом. Ни в коем случае мой дизайн не идеальный, но я надеюсь, что его можно улучшить с каждым входом. Хотя я работаю с ExtJS, общий дизайн также должен применяться к подобным системам, таким как GWT, Flex, Swing и т.д.

Итак, вот он:

Существует четыре типа кода (или информации), которые мы должны иметь в клиентском уровне относительно авторизации:

  • Код манипуляции с элементом GUI, например:

    panel.hide() form.setReadOnly(истина)

  • Требование о разрешении элемента GUI, например:

    form.requires('READ', 'FORM_READ_ROLE')

    adminPanel.requires( 'ADMIN_ROLE')

  • Информация о привилегиях пользователя, которая в основном представляет список ролей, которые пользователь имеет;

  • Логика авторизации: определяет, какие элементы скрывать/отключать на основе прав пользователя;

Ядром проекта является синглтон, названный GUIPermissionManager или GPM для краткости. Это централизованный дизайн, поскольку большая часть кода находится в GPM, так что элементы GUI не загрязняются кодом авторизации. Вот как работает GPM:

  • Элементы GUI (которым требуется определенное разрешение для доступа) регистрируют информацию о разрешении с помощью GPM, например:

    GPM.register(это "DEPARTMENT_DELETE_ROLE" );//кнопка для удаления отдела

  • GPM поддерживает список регистрации разрешения GUI

  • При входе пользователя, GPM получает список ролей, которым назначено использование

  • GPM просматривает список регистрации разрешений GUI и на основании пользовательской привилегии определяет, какая часть GUI скрывается и, в свою очередь, вызывает element.hide() соответственно

Вопросы

  • Элементы GUI организованы в иерархии деревьев, например. панель содержит панель кнопок и форму, поэтому, когда панель скрыта, нет необходимости дополнительно проверять, нужно ли скрывать панель кнопок и форму. Проблема: как регистрировать и поддерживать эту иерархическую информацию в GPM?
  • В настоящее время я могу только думать о двух случаях использования для элемента GUI: скрыть элемент или установить элемент как доступный только для чтения (например, форму). Есть ли другие варианты использования?
  • В ExtJS, чтобы скрыть элемент, мы вызываем hide(), но чтобы установить форму только для чтения, мы должны придумать свою собственную функцию, предположим, что она называется setReadOnly(), как сообщить GPM, что функция для вызова? Передача функции как часть регистрации?
  • Каков наилучший способ установки формы только для чтения? Если я расширю компонент формы с помощью функции setReadOnly(), будет много дублирования кода, и я должен сделать это для каждой формы, требующей разрешения. Возможно ли создать динамический трансформатор формы в GPM, чтобы, если форма установлена ​​только для чтения, она автоматически заменяет все редактируемые поля только полями отображения?
4b9b3361

ОТВЕТЫ

Ответ 1

Q1: Иерархический элемент UI-элемента - Оптимизация вашего GPM, чтобы избежать скрытия элементов, которые уже скрыты через родителя, по-моему, не будет иметь большого увеличения производительности. Мои причины:

  • Вы загружаете разрешения один раз, когда пользователь входит в систему, но не все время.
  • В зависимости от того, как он кодируется, для определения иерархии в любом случае потребуется дополнительная обработка.
  • При надлежащем планировании вы можете избежать регистрации десятков и десятков компонентов и придерживаться всеобъемлющих контейнеров.

Если вы действительно хотите отслеживать иерархическую информацию, вы всегда можете использовать метод 'contains', который все компоненты контейнера предоставляют для проверки того, содержится ли DisplayObject в любом месте своего дочернего списка (включая цепочку). Это может быть вызвано каждый раз, когда компонент зарегистрирован, чтобы проверить, имеет ли он уже зарегистрированного родителя.

Затем в словаре может быть установлен флаг, чтобы игнорировать скрытие этого компонента. Этот флаг может быть проверен первым, итерации по списку зарегистрированных компонентов, чтобы определить, что должно быть скрыто. Словарь может использовать ключи, соответствующие зарегистрированному UID компонента. Кроме того, этот флаг можно использовать для игнорирования компонента, когда приходит время игнорировать другие функции GPM, например, отключение формы (поскольку форма никогда не будет видна в любом случае).

Q2. В верхней части моей головы вы можете отключить/включить компоненты, выполнить изменения состояния или перехватить события, а также все предупреждения. Это действительно слишком широкий вопрос, поскольку все может быть сделано - действительно до дизайнера.

Q3. Вы могли:

  • Укажите параметры при регистрации ваших компонентов, например, чтобы указать, какой тип они (контейнер для скрытия, форма для установки только для чтения и т.д.).
  • Проверяйте каждый компонент, когда он зарегистрирован, чтобы определить, что с ним будет сделано.

Вы, по сути, заключаете контракт с различными компонентами, где GPM знает об их интерфейсах и взаимодействует с ними соответственно.

Q4. Вы всегда можете установить форму для отключения (enabled = false). Это предотвращает любое взаимодействие с пользователем. Некоторые скины изменятся, указывая на то, что компоненты отключены, поэтому вы можете изменить их скины, чтобы предотвратить некоторые из этих действий. В этой строке вы также можете изменить свои скины, чтобы скрыть некоторые элементы, такие как рамка окна TextInput, чтобы он выглядел скорее как "вид", чем отключенный вход.

Было бы возможно создать "трансформатор", который изменяет TextInputs с компонентами RichText и т.д. Это потребует достойной работы и, вероятно, должно быть встроено в расширенный класс Form вместо GPM. Я думаю, что разные состояния скинов для каждого типа компонента могут быть лучшим решением, чтобы избежать создания и уничтожения компонентов, чтобы просто изменить форму формы.

Ответ 2

Обратите внимание! Пользовательские привилегии/авторизация должны контролироваться на стороне сервера, а не на стороне клиента, особенно для веб-приложений js. Это большой риск для безопасности. Вы должны учитывать это в своих рамках.

Изменить - какова ваша структура для управления правами на клиента/личным составом? Это будет главным образом направлять управление вашим GUI на стороне клиента.