MVC 3 страницы безопасности навигации - PullRequest
0 голосов
/ 17 июня 2011

У меня есть приложение MVC3, которое следует шаблону PRG, я ищу лучший способ определить правила навигации для моего приложения.Например, у меня есть приложение со страницами A, B, C и D. Допустим, A - это страница входа.После успешного входа в систему пользователь будет перенаправлен на страницу B. Теперь я не хочу позволять пользователю вводить URL-адрес страницы C в адресной строке и получать доступ к странице C (страница C должна быть доступна только после отправки сообщения на страницу B илисо страницы назад страницы D) Я должен установить аналогичные правила и для всех других страниц (скажем, когда пользователь находится на странице D, не должен позволять им попасть на страницу B)

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

Ценю ваши отзывы !!

Ответы [ 3 ]

1 голос
/ 17 июня 2011

Если вы не хотите, чтобы определенная страница была доступна через URL, один из доступных вариантов - убедиться, что нет доступа к странице через URL. Чтобы получить доступ к странице, выполните действие POST, которое будет возвращать представление, а не перенаправление. Это будет означать, что представление, которое возвращает ваше действие POST, будет отображаться на странице с URL-адресом предыдущей страницы. Для примера:

Страница URL-адрес /login, и после входа пользователь перенаправляется на страницу B. Теперь URL-адрес /home. Страница B отправляет запрос POST, и содержимое страницы становится Страницей C, но URL все еще остается как /home. Единственный способ просмотреть содержимое страницы C - это посетить страницу B и отправить запрос POST.

Это нарушает паттерн PRG, но это один из вариантов.

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

<ч />

Вот краткое подтверждение концепции, описанной выше:

public class PermissionsNeeded : ActionFilterAttribute
{
    string expectedPermission;

    public PermissionsNeeded(string permission)
    {
        expectedPermission = permission;
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        var currentPermissions = filterContext.HttpContext.Session["CurrentPermissions"] as IEnumerable<string> ?? new List<string>();

        // If user does NOT have permission to access the action method
        if(!currentPermissions.Contains(expectedPermission)
        {
            throw new HttpException(403, "User is not authorized to view this page");
        }
    }
}

class YourController : Controller
{
    [HttpPost]
    public ActionResult PageB()
    {
        var currentPermissions = Session["CurrentPermissions"] ?? new List<string>();
        currentPermissions.Add("PostedFromPageB");
        Session["CurrentPermissions"] = currentPermissions;

        return RedirectToAction("PageC");
    }

    [PermissionsNeeded("PostedFromPageB")
    public ActionResult PageC()
    {
        return View();
    }
}

В настоящее время пользовательский атрибут может принимать только одно разрешение за раз, что является простым ограничением для исправления. Вы будете нести ответственность за удаление разрешений, сохраненных в сеансе, если считаете, что у пользователя больше не должно быть определенных разрешений. Я выдал исключение HttpException, которое возвращает код состояния 403 (несанкционированный доступ), но если вместо этого вы хотите вернуть ActionResult, например RedirectToRoute или View, вы можете установить значение для свойства filterContext.Result.

1 голос
/ 17 июня 2011

Не основывайте свою безопасность на этом.Используйте атрибут [Authorize] для определения безопасности.UrlReferrer также может быть легко подделан.

Почему вы пытаетесь ограничить это?Если у вас есть бизнес-причина, по которой пользователь чаще всего проходит через определенный поток, то рассмотрите файл cookie, сеанс или запись в базе данных, чтобы отметить их текущий статус «завершения» - например, IE - какой-то несколько постоянный метод для определения этого.Вы также можете сформировать токен на основе, скажем, идентификатора сеанса, который передается на каждую страницу.Если токен существует и соответствует текущему сеансу пользователя, загрузите для него страницу.Конечно, это может быть подделано, если пользователь это понимает - но если вы просто пытаетесь обеспечить правильный поток, то это тоже путь.Пользователь не получит ссылку с идентификатором текущей сессии, пока не достигнет предыдущего шага.

0 голосов
/ 20 июня 2011

Я выполняю эту задачу, как показано ниже:

  1. При успешном завершении каждой страницы сохраните Имя страницы в базе данных
  2. Когда пользователь запрашивает новую страницу, просто проверьте последнюю страницу, которую он завершил, из базы данных и решите, что делать.

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

Спасибо всем за ваши ответы!

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