2013-04-13 2 views
1

В старые времена:Использование перенаправления из HttpModule в качестве веб-сайта MVC, «правильный» путь

Мы использовали Response.Redirect, который устанавливает заголовок в 302 ответа и поднимает ThreadAbortException, чтобы предотвратить что-нибудь еще от происходящего после перенаправления.

Теперь, с MVC:

Мы возвращаем RedirectResult, что позволяет избежать проблем с производительностью ThreadAbortException, а также позволяет остальную часть трубопровода, чтобы осмотреть результаты, прежде чем фактически отправляя их обратно в браузер. Это другой способ мышления о переадресации - теперь вместо того, чтобы прекратить выполнение, перенаправление больше напоминает возврат из функции.

Мой вопрос связан с смешиванием и сопоставлением этих шаблонов.

Вот это требование. У нас есть сайт MVC, а сайт содержит HttpModule, который отвечает за аутентификацию. Если что-то пойдет не так с проверкой подлинности, оно удаляет файлы cookie и перенаправляет на внешнюю страницу . Таким образом, HttpModule принимает решение о отправке заголовка перенаправления или управления передачей на сайт MVC. Если он отправляет заголовок перенаправления, он должен остановить выполнение - если аутентификация завершилась неудачно, мы не хотим, чтобы сайт был доступен каким-либо образом, формой или формой.

Что такое «правильный» способ сделать это? Должен ли HttpModule просто использовать Response.Redirect так же, как мы всегда это делали? Или есть какой-то умный способ добиться этого, что более соответствует шаблону MVC? Есть ли способ, которым HttpModule может сказать, что конвейер перестает обрабатывать?

Или я должен использовать какой-то совершенно другой шаблон, то, что не использует HttpModule? Возможно, фильтр MVC? Дело в том, что модульность/разделение проблем между модулем и самим сайтом очень важны. У кого-нибудь есть рекомендации?

ответ

1

Поскольку вы упомянули об этом для аутентификации, вы должны использовать Authorize Attribute. Вы можете использовать его либо на уровне класса, либо на уровне действия.

[Authorize] 
public class HomeController : Controller 
{ 
    // All actions will require authorization 
} 

public class ImageController : Controller 
{ 
    public ActionResult PublicImage() 
    { 
    } 

    [Authorize] 
    public ActionResult ImageRequiringAuth() 
    { 
    } 
} 

Для вашего случая использования, возможно, потребуется, чтобы наследовать от AuthorizationAttribute, как описано в этом answer.

+0

Спасибо, Джон за ваш ответ. Я посмотрел на такой подход. Вот две причины, по которым я решил против: 1. Команда, которая работает по аутентификации, отделена от команды, которая работает в пользовательском интерфейсе. Подход к атрибуции требует модификации самого кода сайта. Я надеялся на более детализированный подход, где я мог бы удалить DLL в папку bin, добавить конфигурацию и сделать это. 2. Модуль, над которым мы работаем, перехватывает все запросы, а не только запросы на действия, определенные на веб-сайте (например, обработчики для входа и выхода из системы, которые не реализованы как действия веб-сайта). –

2

Думал, что я бы ответил на этот вопрос, если у кого-то еще есть вопрос в подобной проблемной области.

Ответ на самом деле очень простой. не

HttpContext.ApplicationInstance.CompleteRequest() 

выше вызова больше не бросает ThreadAbortException (это изменилось с .NET 2.0), поэтому вы можете смело использовать его, чтобы сказать, трубопровод, чтобы остановить выполнение. Когда HttpModule выходит из строя, собственный веб-сайт обходит, и управление переходит непосредственно в EndRequest - именно то, что мне нужно. Это было невозможно в .NET 1.1, но я не думаю, что там много проектов 1.1 MVC;)

 Смежные вопросы

  • Нет связанных вопросов^_^