Как создавать страницы с разными разрешениями просмотров - PullRequest
0 голосов
/ 03 марта 2011

Мне нужно создать разные просмотры страниц для разных типов пользователей.Я уже спрашивал это здесь: Как создавать страницы с различными разрешениями

И хотя ответ Алдела работает, он не кажется мне лучшим решением.Я объясню почему.

Я постараюсь объяснить, что мне нужно, очень подробно, и, надеюсь, некоторые из вас смогут мне помочь: D

Мне нужно показать разные взгляды, ноэто не только так.Каждый пользователь может иметь доступ к различным частям страницы.

Я приведу пример:

Представьте себе страницу 'X' с этой структурой

Field A
Field B
Field C
Field D

Когдапользователь U1 из группы G1 посещение страницы X система проверяет базу данных для разрешения этой группы на странице X.Пользователь U1 может видеть Field A и Field B, но может редактировать только Field A.

Пользователь U2, для которого не заданы посещения группы X.Система проверяет его разрешения на странице X.Пользователь U2 может видеть и редактировать все поля.

Когда пользователь U3 из группы G2 посещает страницу X, система проверяет БД на наличие разрешения этой группы на странице X.Пользователь U3 может видеть Field C и Field D, но не может их редактировать.

Я надеюсь, что это легко понять ...

Я не могу найти способ сделатьчто вместо заполнения ViewData большим количеством данных о разрешении этого конкретного пользователя.В моем примере есть только 4 поля, но в моем текущем проекте у меня нет экрана с менее чем 20 полями.Так что, я думаю, вы видите, насколько это уродливо и непродуктивно.

Идея похожа на социальную сеть, как я уже сказал ( пример на Facebook ).Когда пользователь, посещающий страницу UserX, может видеть только то, что ему позволил UserX.

Я действительно ценю любую помощь.

С уважением.

Ответы [ 2 ]

4 голосов
/ 03 марта 2011

Чтобы делать то, что вы хотите сделать, вам не нужно контролировать свои представления - на самом деле вы должны защищать свои контроллеры, а не представления.Вы можете сделать это через атрибуты контроллера.Что-то похожее на это:

[Authorize]
public class MyController {
}

Этим вы защищаете весь контроллер.Каждое действие в этом контроллере не будет отвечать, если пользователь не аутентифицирован (в частности, он получит ответ 401).Вы можете расширить это, авторизовав отдельных пользователей или отдельные роли, как показано в примерах ниже:

[Authorize(Users="eestein,JasCav")
public class MyController {
}

[Authorize(Roles="Administrator")]
public class MyController {
}

В вашем случае вы можете не захотеть иметь весь контроллер с авторизацией на нем.Что ж, достаточно превосходно, ASP.NET MVC обеспечивает контроль аутентификации на уровне действий.Итак, вы можете сделать это:

public class MyController {

    public ActionResult Index() { }

    [Authorize(Roles="Administrator")]
    public ActionResult Admin() { }

}

Используя эту идею, вы можете контролировать то, что пользователь видит на странице.Вы захотите вернуть частичные страницы из ваших действий, чтобы вы могли загружать различные аспекты страницы.Например, у вас может быть представление, которое показывает некоторые нормальные данные и некоторые секретные данные.Нормальные данные могут быть возвращены через обычную страницу.Секретные данные должны быть возвращены как частичное представление на странице.Однако, если происходит 401, вы можете справиться с этим и просто ничего не показывать.

Это довольно просто сделать.Команда .NET отлично поработала над настройкой, и вам не нужно отдельно проверять разрешения в вашем контроллере.Я надеюсь, что это поможет вам начать.Выполните поиск в Интернете для получения дополнительной информации о том, как использовать атрибут авторизации.

Обновление В случае, если у вас есть администратор страницы, который контролирует эти разрешения, вы должны быть умнымио том, как вы устанавливаете свой атрибут Authorize.Именно здесь очень важны «роли» (согласно моим примерам выше).Например, если администратор скажет: «Я собираюсь добавить Джона Доу в роль SpecialUser», тогда пользователь Джона Доу сможет получить доступ ко всем действиям, для которых установлена ​​роль SpecialUser (если это действительно так.роль в вашей системе).

Очевидно, что вам придется предоставить администраторам некоторый способ сделать это, и атрибут Authorize делает это отлично.Чтобы увидеть, у кого есть разрешения на странице, вам нужно будет запросить базу данных, чтобы узнать, кто является частью какой роли.Вот способ подумать о настройке:

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

Надеюсь, это прояснится (и, надеюсь, я достаточно хорошо понял вашу проблему).Я думаю, что то, что вы пытаетесь сделать, возможно.

Обновление 2 Да, это предполагает, что у вас есть статические группы на контроллерах, и любая новая группа должна быть добавлена ​​программно.Мне было бы любопытно узнать, какой вариант использования требует создания разных типов разрешений на лету - кажется, что он может быть открыт для злоупотреблений.В любом случае у меня нет решения для этого.

Что касается того, как работают частичные представления ... это что-то вроде этого ...

public class ProductController : Controller
{
    //
    // GET: /Index/
    public ActionResult Index()
    {
        return View();
    }

    public ActionResult Partial1()
    {
       return PartialView();
    }

    [Authorize]
    public ActionResult Partial2()
    {
       return PartialView();
    }
}

Внутри вашего Index.aspxфайл, у вас будет что-то вроде этого:

<%= Html.RenderAction("Partial1") %>
<%= Html.RenderAction("Partial2") %>

Если пользователь не авторизован, вы можете обработать второй RenderAction, так что представление даже не отображается.(Вы можете проверить это в своем контроллере.)

Надеюсь, это прояснит ситуацию!Я нахожусь в бегах, поэтому я не могу больше на этом разбираться.

1 голос
/ 03 марта 2011

Я бы рекомендовал «аддитивную» безопасность;Разрешения пользователя и любой из его групп объединяются, чтобы дать серию действий, которые ему разрешено делать.Если у него нет явного разрешения на то, для чего требуется разрешение, ему не разрешается это делать.В вашем случае между пользователем U1 и группой G1 есть достаточные разрешения, предоставленные пользователю для просмотра поля A и поля B, а также для редактирования поля A. Поскольку пользователю, либо самим, либо через свою группу, явно не было предоставлено разрешение наотредактируйте поле B или просмотрите ИЛИ отредактируйте поля C и D, он не имеет этих разрешений.

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

Что нужно знать:

  • Убедитесь, что вы используете сервер .NETинструменты для показа / скрытия полей.Если для свойства Visible поля установлено значение false на стороне сервера, отображаемая страница даже не будет включать это поле в HTML.Напротив, добавление стиля или использование JavaScript для скрытия свойств сохраняет их в DOM и в HTML, поэтому человек может «просматривать исходный код», чтобы просматривать скрытые таким образом поля.
  • НИКОГДА не использовать на стороне клиентакод для реализации безопасности.JavaScript, элементы управления ActiveX и т. Д. Могут быть отклонены, отключены и / или изменены.Клиентский код для отображения данных также требует, чтобы данные располагались где-то в источнике страницы, то есть их очень легко найти, просмотрев источник страницы.
  • По тому же признаку, не верьте, чтов редактируемом поле его данные не будут изменены.HTML и код на стороне клиента можно очень легко изменить с помощью таких инструментов, как FireBug.
  • Ваш код будет более безопасным, если вы начнете со всего невидимого / отключенного и сделаете его видимым / включенным, чем если бы вы начали сшироко открытый доступ и скрыть вещи.Если вы забудете спрятать что-то новое, вдруг клиенты увидят новое поле, к которому они не должны прикасаться.Если вы забыли добавить код для отображения нового поля на основе разрешений, вам все равно придется его исправить, но гораздо труднее или невозможно использовать поле, которое не существует.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...