□ ExceptionType — указывает тип исключения, на возникновение которого должен реагировать данный атрибут;
□ View — указывает представление, которое нужно показать пользователю при срабатывании атрибута;
□ Master — указывает наименование Master View, которое будет использоваться при демонстрации пользователю представления;
□ Order — указывает на последовательный номер, в порядке которого атрибут будет исполняться.
Для демонстрации работы атрибута HandleErrorAttribute создадим представление AdminError, которое будет использоваться только тогда, когда произойдет ошибка при работе с контроллером AdminController. В листинге 4.3 представлен код представления.
<%@ Page Title="" Language="C#"
MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage" %>
<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent"
runat="server">
Ошибка! Произошло необработанное исключение.
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent"
runat="server">
<% var model = (HandleErrorlnfo)ViewData.Model; %>
<h2>Внимание</h2>
<р>При работе сайта произошла исключительная
ситуация в действии <%= model.ActionName %>
контроллера <%= model.ControllerName %>.
Ниже представлена дополнительная информация об исключении:
</p>
<p><%= model.Exception.Message %></p>
<p><%= model.Exception.StackTrace %></p>
</asp:Content>
Обратите внимание, для получения доступа к расширенной информации об исключении мы используем свойство Model объекта ViewData, предварительно приведя его к типу HandleErrorInfo. Механизм атрибута HandleErrorAttribute создает для представления элемент типа HandleErrorInfo, объект которого содержит следующие данные:
□ ActionName — имя действия, в котором произошло исключение;
□ ControllerName — имя контроллера, в котором произошло исключение;
□ Exception - объект типа Exception, в котором содержится вся информация об исключении, в том числе строка сообщения и трассировка стека.
Для того чтобы проверить наше представление, создадим для тестирования новое действие TestException в контроллере AdminController:
public ActionResult TestException()
{
throw new Exception("Проверка исключения");
}
Пометим наш контроллер AdminController атрибутом HandleErrorAttribute в следующем виде, как это показано во фрагменте:
[HandleError(View = "AdminError")]
public class AdminController : Controller
Теперь, чтобы механизм атрибута HandleErrorAttribute заработал, необходимо включить механизм Custom Errors в файле web.config так, как показано во фрагменте:
<customErrors mode="On" />
После запуска приложения и попытки доступа к действию TestException мы получим сообщение об ошибке (рис. 4.8).
Кроме перечисленного, атрибут HandleErrorAttribute имеет ряд важных особенностей:
□ если механизм Custom Errors запрещен, или исключение уже было обработано другим атрибутом, то исполнение атрибута прекращается;
□ если исключение является HTTP-исключением с кодом, отличным от 500, исполнение атрибута прекращается. Другими словами, этот атрибут не обрабатывает HTTP-исключения с любыми кодами ошибок, кроме 500;
□ атрибут устанавливает Response.TrySkipIisCustomErrors = true для того, чтобы попытаться переопределить страницы веб-сервера, настроенные для отображения ошибок;
□ атрибут устанавливает код HTTP-ответа в значение 500, которое сообщает клиенту о возникшей при запросе ошибке.
Использование атрибута HandleErrorAttribte позволяет гибко настраивать реакцию вашего приложения на возникновение исключительных ситуаций.
Вы можете определять для каждого контроллера, действия или типа исключения свои представления вывода информации об ошибке.
ValidateAntiForgeryTokenAttribute
Проблема безопасности в современном Интернете не заканчивается вместе с проверкой права доступа на базе неких правил, ролей или пользователей.
Вместе с возможностями защиты от несанкционированного доступа изменяются и способы проникновения и взлома защиты. Одним из таких способов проникнуть через защиту сайта является атака под названием Cross-site Request Forgery Attack (CSRF). Суть этой атаки заключается в следующем:
□ сайт должен иметь авторизацию по cookies, а пользователь, через которого планируется атака, должен иметь возможность автоматической авторизации;
□ на некой специальной странице в Интернете создается элемент формы со скрытыми параметрами и автоматическим отправлением этих данных по адресу сайта, на котором зарегистрирован пользователь;
□ при посещении страницы, подготовленной злоумышленником, пользователь, сам того не предполагая, авторизуется на своем сайте и выполняет некий запрос, который может делать все, что угодно, от простого принудительного "выхода" пользователя из системы до отправки неких данных на сервер в контексте авторизованного пользователя.
Опасность такой атаки очень велика, для того чтобы защититься, существует один простой, но действенный метод. К любой форме на странице добавляется скрытое поле с неким генерируемым значением, это же значение записывается в пользовательское cookie. После отправки запроса значение поля сравнивается на сервере со значением cookie, и если значения не совпадают, считается, что производится нелегальный запрос. Злоумышленник не сможет сгенерировать те же самые коды, и поэтому его попытки провести такого рода атаку будут бесполезными.
Механизм ASP.NET MVC имеет поддержку такого рода защиты в виде атрибута ValidateAntiForgeryTokenAttribute и helper-метода Html.AntiForgeryToken. В нашем примере с контроллером AdminController есть слабое и уязвимое место — это действие Delete, которое выполняется с помощью GET-запросов и может быть использовано злоумышленником для того, чтобы преднамеренно удалять данные о пользователях. Правильно сформированные формы не должны разрешать любые модификации данных по GET-запросам. Иными словами, GET-запросы должны выполнять действия "только для чтения", а все остальные действия должны происходить через POST-запросы. Перепишем наш механизм действия Delete и добавим к нему и действию Update поддержку атрибута ValidateAntiForgeryTokenAttribute, для этого изменим разметку представления так, как показано в следующем фрагменте:
<% using (Html.BeginForm("Update", "Admin")) { %>
<%= Html.Hidden("userId", (Guid)user.ProviderUserKey) %>
<%= Html.AntiForgeryToken() %>
<fieldset>
<legend>Данные</legend>
<p>
<label for="email">Email</label>
<%=Html.TextBox("email", user.Email)%>
</Р>
<p>
<label for="isApproved"><%=Html.CheckBox("isApproved",
user.IsApproved)%>подтвержден