Главная › Услуги › Собственная авторизация asp net mvc. Контроль доступа к определенным каталогам. Управление доступом на основе групп и ролей

Собственная авторизация asp net mvc. Контроль доступа к определенным каталогам. Управление доступом на основе групп и ролей

cURL - это специальный инструмент, который предназначен для того, чтобы передавать файлы и данные синтаксисом URL. Данная технология поддерживает множество протоколов, таких как HTTP, FTP, TELNET и многие другие. Изначально cURL было разработано для того, чтобы быть инструментом командной строки. К счастью для нас, библиотека cURL поддерживается языком программирования PHP. В этой статье мы рассмотрим некоторые расширенные функций cURL, а также затронем практическое применение полученных знаний средствами PHP.

Почему cURL?

На самом деле, существует немало альтернативных способов выборки содержания веб-страницы. Во многих случаях, главным образом из-за лени, я использовал простые PHP функции вместо cURL:

$content = file_get_contents("http://www.nettuts.com"); // или $lines = file("http://www.nettuts.com"); // или readfile("http://www.nettuts.com");

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

cURL - это мощная библиотека, которая поддерживает множество различных протоколов, опций и обеспечивает подробную информацию о URL запросах.

Базовая структура

Инициализация
Назначение параметров
Выполнение и выборка результата
Освобождение памяти

// 1. инициализация $ch = curl_init(); // 2. указываем параметры, включая url curl_setopt($ch, CURLOPT_URL, "http://www.nettuts.com"); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_HEADER, 0); // 3. получаем HTML в качестве результата $output = curl_exec($ch); // 4. закрываем соединение curl_close($ch);

Шаг #2 (то есть, вызов curl_setopt()) будем обсуждать в этой статье намного больше, чем все другие этапы, т.к. на этой стадии происходит всё самое интересное и полезное, что вам необходимо знать. В cURL существует огромное количество различных опций, которые должны быть указаны, для того чтобы иметь возможность сконфигурировать URL-запрос самым тщательным образом. Мы не будем рассматривать весь список целиком, а остановимся только на том, что я посчитаю нужным и полезным для этого урока. Всё остальное вы сможете изучить сами, если эта тема вас заинтересует.

Проверка Ошибки

Вдобавок, вы также можете использовать условные операторы для проверки выполнения операции на успех:

// ... $output = curl_exec($ch); if ($output === FALSE) { echo "cURL Error: " . curl_error($ch); } // ...

Тут прошу отметить для себя очень важный момент: мы должны использовать “=== false” для сравнения, вместо “== false”. Для тех, кто не в курсе, это поможет нам отличать пустой результат от булевого значения false, которое и будет указывать на ошибку.

Получение информации

Ещё одним дополнительным шагом является получение данных о cURL запросе, после того, как он был выполнен.

// ... curl_exec($ch); $info = curl_getinfo($ch); echo "Took " . $info["total_time"] . " seconds for url " . $info["url"]; // …

Возвращаемый массив содержит следующую информацию:

“url”
“content_type”
“http_code”
“header_size”
“request_size”
“filetime”
“ssl_verify_result”
“redirect_count”
“total_time”
“namelookup_time”
“connect_time”
“pretransfer_time”
“size_upload”
“size_download”
“speed_download”
“speed_upload”
“download_content_length”
“upload_content_length”
“starttransfer_time”
“redirect_time”

Обнаружение перенаправления в зависимости от браузера

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

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

// тестируем URL $urls = array("http://www.cnn.com", "http://www.mozilla.com", "http://www.facebook.com"); // тестируем браузеры $browsers = array("standard" => array ("user_agent" => "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)", "language" => "en-us,en;q=0.5"), "iphone" => array ("user_agent" => "Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A537a Safari/419.3", "language" => "en"), "french" => array ("user_agent" => "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6; .NET CLR 2.0.50727)", "language" => "fr,fr-FR;q=0.5")); foreach ($urls as $url) { echo "URL: $url\n"; foreach ($browsers as $test_name => $browser) { $ch = curl_init(); // указываем url curl_setopt($ch, CURLOPT_URL, $url); // указываем заголовки для браузера curl_setopt($ch, CURLOPT_HTTPHEADER, array("User-Agent: {$browser["user_agent"]}", "Accept-Language: {$browser["language"]}")); // нам не нужно содержание страницы curl_setopt($ch, CURLOPT_NOBODY, 1); // нам необходимо получить HTTP заголовки curl_setopt($ch, CURLOPT_HEADER, 1); // возвращаем результаты вместо вывода curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $output = curl_exec($ch); curl_close($ch); // был ли HTTP редирект? if (preg_match("!Location: (.*)!", $output, $matches)) { echo "$test_name: redirects to $matches\n"; } else { echo "$test_name: no redirection\n"; } } echo "\n\n"; }

Сначала мы указываем список URL сайтов, которые будем проверять. Точнее, нам понадобятся адреса данных сайтов. Далее нам необходимо определить настройки браузера, чтобы протестировать каждый из этих URL. После этого мы воспользуемся циклом, в котором пробежимся по всем полученным результатам.

Приём, который мы используем в этом примере для того, чтобы задать настройки cURL, позволит нам получить не содержание страницы, а только HTTP-заголовки (сохраненные в $output). Далее, воспользовавшись простым regex, мы можем определить, присутствовала ли строка “Location:” в полученных заголовках.

Когда вы запустите данный код, то должны будете получить примерно следующий результат:

Создание POST запроса на определённый URL

При формировании GET запроса передаваемые данные могут быть переданы на URL через “строку запроса”. Например, когда Вы делаете поиск в Google, критерий поиска располагаются в адресной строке нового URL:

Http://www.google.com/search?q=ruseller

Для того чтобы сымитировать данный запрос, вам не нужно пользоваться средствами cURL. Если лень вас одолевает окончательно, воспользуйтесь функцией “file_get_contents()”, для того чтобы получить результат.

Но дело в том, что некоторые HTML-формы отправляют POST запросы. Данные этих форм транспортируются через тело HTTP запроса, а не как в предыдущем случае. Например, если вы заполнили форму на форуме и нажали на кнопку поиска, то скорее всего будет совершён POST запрос:

Http://codeigniter.com/forums/do_search/

Мы можем написать PHP скрипт, который может сымитировать этот вид URL запроса. Сначала давайте создадим простой файл для принятия и отображения POST данных. Назовём его post_output.php:

Print_r($_POST);

Затем мы создаем PHP скрипт, чтобы выполнить cURL запрос:

$url = "http://localhost/post_output.php"; $post_data = array ("foo" => "bar", "query" => "Nettuts", "action" => "Submit"); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); // указываем, что у нас POST запрос curl_setopt($ch, CURLOPT_POST, 1); // добавляем переменные curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data); $output = curl_exec($ch); curl_close($ch); echo $output;

При запуске данного скрипта вы должны получить подобный результат:

Таким образом, POST запрос был отправлен скрипту post_output.php, который в свою очередь, вывел суперглобальный массив $_POST, содержание которого мы получили при помощи cURL.

Загрузка файла

Сначала давайте создадим файл для того, чтобы сформировать его и отправить файлу upload_output.php:

Print_r($_FILES);

А вот и код скрипта, который выполняет указанный выше функционал:

$url = "http://localhost/upload_output.php"; $post_data = array ("foo" => "bar", // файл, который необходимо загрузить "upload" => "@C:/wamp/www/test.zip"); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data); $output = curl_exec($ch); curl_close($ch); echo $output;

Когда вы хотите загрузить файл, все, что вам нужно сделать, так это передать его как обычную post переменную, предварительно поместив перед ней символ @. При запуске написанного скрипта вы получите следующий результат:

Множественный cURL

Одной из самых сильных сторон cURL является возможность создания "множественных" cURL обработчиков. Это позволяет вам открывать соединение к множеству URL одновременно и асинхронно.

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

Давайте рассмотрим пример кода, который я взял с php.net:

// создаём несколько cURL ресурсов $ch1 = curl_init(); $ch2 = curl_init(); // указываем URL и другие параметры curl_setopt($ch1, CURLOPT_URL, "http://lxr.php.net/"); curl_setopt($ch1, CURLOPT_HEADER, 0); curl_setopt($ch2, CURLOPT_URL, "http://www.php.net/"); curl_setopt($ch2, CURLOPT_HEADER, 0); //создаём множественный cURL обработчик $mh = curl_multi_init(); //добавляем несколько обработчиков curl_multi_add_handle($mh,$ch1); curl_multi_add_handle($mh,$ch2); $active = null; //выполнение do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); while ($active && $mrc == CURLM_OK) { if (curl_multi_select($mh) != -1) { do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); } } //закрытие curl_multi_remove_handle($mh, $ch1); curl_multi_remove_handle($mh, $ch2); curl_multi_close($mh);

Идея состоит в том, что вы можете использовать множественные cURL обработчики. Используя простой цикл, вы можете отследить, какие запросы ещё не выполнились.

В этом примере есть два основных цикла. Первый цикл do-while вызывает функцию curl_multi_exec(). Эта функция не блокируемая. Она выполняется с той скоростью, с которой может, и возвращает состояние запроса. Пока возвращенное значение является константой ‘CURLM_CALL_MULTI_PERFORM’, это означает, что работа ещё не завершена (например, в данный момент происходит отправка http заголовков в URL); Именно поэтому мы продолжаем проверять это возвращаемое значение, пока не получим другой результат.

В следующем цикле мы проверяем условие, пока переменная $active = "true". Она является вторым параметром для функции curl_multi_exec(). Значение данной переменной будет равно "true", до тех пор, пока какое-то из существующих изменений является активным. Далее мы вызываем функцию curl_multi_select(). Её выполнение "блокируется", пока существует хоть одно активное соединение, до тех пор, пока не будет получен ответ. Когда это произойдёт, мы возвращаемся в основной цикл, чтобы продолжить выполнение запросов.

А теперь давайте применим полученные знания на примере, который будет реально полезным для большого количества людей.

Проверяем ссылки в WordPress

Представьте себе блог с огромным количеством постов и сообщений, в каждом из которых есть ссылки на внешние интернет ресурсы. Некоторые из этих ссылок по различным причинам могли бы уже быть «мертвыми». Возможно, страница была удалена или сайт вовсе не работает.

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

Сразу же скажу, что это не пример создания плагина для WordPress. Это всего на всего хороший полигон для наших испытаний.

Давайте же наконец начнём. Сначала мы должны сделать выборку всех ссылок из базы данных:

// конфигурация $db_host = "localhost"; $db_user = "root"; $db_pass = ""; $db_name = "wordpress"; $excluded_domains = array("localhost", "www.mydomain.com"); $max_connections = 10; // инициализация переменных $url_list = array(); $working_urls = array(); $dead_urls = array(); $not_found_urls = array(); $active = null; // подключаемся к MySQL if (!mysql_connect($db_host, $db_user, $db_pass)) { die("Could not connect: " . mysql_error()); } if (!mysql_select_db($db_name)) { die("Could not select db: " . mysql_error()); } // выбираем все опубликованные посты, где есть ссылки $q = "SELECT post_content FROM wp_posts WHERE post_content LIKE "%href=%" AND post_status = "publish" AND post_type = "post""; $r = mysql_query($q) or die(mysql_error()); while ($d = mysql_fetch_assoc($r)) { // делаем выборку ссылок при помощи регулярных выражений if (preg_match_all("!href=\"(.*?)\"!", $d["post_content"], $matches)) { foreach ($matches as $url) { $tmp = parse_url($url); if (in_array($tmp["host"], $excluded_domains)) { continue; } $url_list = $url; } } } // убираем дубликаты $url_list = array_values(array_unique($url_list)); if (!$url_list) { die("No URL to check"); }

Сначала мы формируем конфигурационные данные для взаимодействия с базой данных, далее пишем список доменов, которые не будут участвовать в проверке ($excluded_domains). Также мы определяем число, характеризующее количество максимальных одновременных соединений, которые мы будем использовать в нашем скрипте ($max_connections). Затем мы присоединяемся к базе данных, выбираем посты, которые содержат ссылки, и накапливаем их в массив ($url_list).

Следующий код немного сложен, так что разберитесь в нём от начала до конца:

// 1. множественный обработчик $mh = curl_multi_init(); // 2. добавляем множество URL for ($i = 0; $i < $max_connections; $i++) { add_url_to_multi_handle($mh, $url_list); } // 3. инициализация выполнения do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); // 4. основной цикл while ($active && $mrc == CURLM_OK) { // 5. если всё прошло успешно if (curl_multi_select($mh) != -1) { // 6. делаем дело do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); // 7. если есть инфа? if ($mhinfo = curl_multi_info_read($mh)) { // это значит, что запрос завершился // 8. извлекаем инфу $chinfo = curl_getinfo($mhinfo["handle"]); // 9. мёртвая ссылка? if (!$chinfo["http_code"]) { $dead_urls = $chinfo["url"]; // 10. 404? } else if ($chinfo["http_code"] == 404) { $not_found_urls = $chinfo["url"]; // 11. рабочая } else { $working_urls = $chinfo["url"]; } // 12. чистим за собой curl_multi_remove_handle($mh, $mhinfo["handle"]); // в случае зацикливания, закомментируйте данный вызов curl_close($mhinfo["handle"]); // 13. добавляем новый url и продолжаем работу if (add_url_to_multi_handle($mh, $url_list)) { do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); } } } } // 14. завершение curl_multi_close($mh); echo "==Dead URLs==\n"; echo implode("\n",$dead_urls) . "\n\n"; echo "==404 URLs==\n"; echo implode("\n",$not_found_urls) . "\n\n"; echo "==Working URLs==\n"; echo implode("\n",$working_urls); function add_url_to_multi_handle($mh, $url_list) { static $index = 0; // если у нас есть ещё url, которые нужно достать if ($url_list[$index]) { // новый curl обработчик $ch = curl_init(); // указываем url curl_setopt($ch, CURLOPT_URL, $url_list[$index]); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); curl_setopt($ch, CURLOPT_NOBODY, 1); curl_multi_add_handle($mh, $ch); // переходим на следующий url $index++; return true; } else { // добавление новых URL завершено return false; } }

Тут я попытаюсь изложить всё по полочкам. Числа в списке соответствуют числам в комментарии.

1. Создаём множественный обработчик;
2. Функцию add_url_to_multi_handle() мы напишем чуть позже. Каждый раз, когда она будет вызываться, начнётся обработка нового url. Первоначально, мы добавляем 10 ($max_connections) URL;
3. Для того чтобы начать работу, мы должны запустить функцию curl_multi_exec(). До тех пор, пока она будет возвращать CURLM_CALL_MULTI_PERFORM, нам ещё есть, что делать. Это нам нужно, главным образом, для того, чтобы создать соединения;
4. Далее следует основной цикл, который будет выполняться до тех пор, пока у нас есть хоть одно активное соединение;
5. curl_multi_select() зависает в ожидании, пока поиск URL не завершится;
6. И снова мы должны заставить cURL выполнить некоторую работу, а именно, сделать выборку данных возвращаемого ответа;
7. Тут происходит проверка информации. В результате выполнения запроса будет возвращён массив;
8. В возвращенном массиве присутствует cURL обработчик. Его мы и будем использовать для того, чтобы выбрать информацию об отдельном cURL запросе;
9. Если ссылка была мертва, или время выполнения скрипта вышло, то нам не следует искать никакого http кода;
10. Если ссылка возвратила нам страницу 404, то http код будет содержать значение 404;
11. В противном случае, перед нами находится рабочая ссылка. (Вы можете добавить дополнительные проверки на код ошибки 500 и т.д...);
12. Далее мы удаляем cURL обработчик, потому что больше в нём не нуждаемся;
13. Теперь мы можем добавить другой url и запустить всё то, о чём говорили до этого;
14. На этом шаге скрипт завершает свою работу. Мы можем удалить всё, что нам не нужно и сформировать отчет;
15. В конце концов, напишем функцию, которая будет добавлять url в обработчик. Статическая переменная $index будет увеличиваться каждый раз, когда данная функция будет вызвана.

Я использовал данный скрипт на своем блоге (с некоторыми неработающими ссылками, которые добавил нарочно для того, чтобы протестировать его работу) и получил следующий результат:

В моём случае, скрипту потребовалось чуть меньше чем 2 секунды, чтобы пробежаться по 40 URL. Увеличение производительности является существенным при работе с еще большим количеством URL адресов. Если вы открываете десять соединений одновременно, то скрипт может выполниться в десять раз быстрее.

Пару слов о других полезных опциях cURL

HTTP Аутентификация

Если на URL адресе есть HTTP аутентификация, то вы без труда можете воспользоваться следующим скриптом:

$url = "http://www.somesite.com/members/"; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); // указываем имя и пароль curl_setopt($ch, CURLOPT_USERPWD, "myusername:mypassword"); // если перенаправление разрешено curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); // то сохраним наши данные в cURL curl_setopt($ch, CURLOPT_UNRESTRICTED_AUTH, 1); $output = curl_exec($ch); curl_close($ch);

FTP загрузка

В PHP также существует библиотека для работы с FTP, но вам ничего не мешает и тут воспользоваться средствами cURL:

// открываем файл $file = fopen("/path/to/file", "r"); // в url должно быть следующее содержание $url = "ftp://username:[email protected]:21/path/to/new/file"; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_UPLOAD, 1); curl_setopt($ch, CURLOPT_INFILE, $fp); curl_setopt($ch, CURLOPT_INFILESIZE, filesize("/path/to/file")); // указывам ASCII мод curl_setopt($ch, CURLOPT_FTPASCII, 1); $output = curl_exec($ch); curl_close($ch);

Используем Прокси

Вы можете выполнить свой URL запрос через прокси:

$ch = curl_init(); curl_setopt($ch, CURLOPT_URL,"http://www.example.com"); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); // указываем адрес curl_setopt($ch, CURLOPT_PROXY, "11.11.11.11:8080"); // если необходимо предоставить имя пользователя и пароль curl_setopt($ch, CURLOPT_PROXYUSERPWD,"user:pass"); $output = curl_exec($ch); curl_close ($ch);

Функции обратного вызова

Также существует возможность указать функцию, которая будет срабатывать ещё до завершения работы cURL запроса. Например, пока содержание ответа загружается, вы можете начать использовать данные, не дожидаясь полной загрузки.

$ch = curl_init(); curl_setopt($ch, CURLOPT_URL,"http://net.tutsplus.com"); curl_setopt($ch, CURLOPT_WRITEFUNCTION,"progress_function"); curl_exec($ch); curl_close ($ch); function progress_function($ch,$str) { echo $str; return strlen($str); }

Подобная функция ДОЛЖНА возвращать длину строки, что является обязательным требованием.

Заключение

Сегодня мы познакомились с тем, как можно применить библиотеку cURL в своих корыстных целях. Я надеюсь, что вам понравилась данная статья.

Спасибо! Удачного дня!

Вы создали WebAPI и теперь хотите контролировать доступ к нему? В этой серии статей мы рассмотрим несколько вариантов защиты WebAPI от неавторизрованых пользователей. Серия будет охватывать обе стороны, и аутентификацию и авторизацию пользователей.

Аутентификация - позволяет однозначно идентифицировать пользователя. Например, Алиса входит в систему со своим логином и паролем, и сервер использует эти данные для аутентификации Алисы.
Авторизация решает может ли пользователь выполнить те или иные действия. Например, Алиса может иметь право на чтение ресурса, но не может создать новый ресурс.

Первая серия статей дает общий обзор аутентификации и авторизации в ASP.NET Web API. Другие статьи описывают общие сценарии аутентификации для WebAPI.

Аутентификация

WebAPI предполагает что аутентификацию проводит хост, в котором он размещается. Для веб-хостинга хостом является IIS, который использует HTTP модули для аутентификации. Вы можете сконфигурировать свой проект на использование модулей аутентификации встроенных в IIS или ASP.NET, или же написать собственный модуль HTTP, для выполнения кастомной проверки подлинности.

Когда хост проводит аутентификацию пользователя, он создает объект IPrincipal, который представляет собой контекст безопасности в котором исполняется код. Созданный объект прикрепляет к текущему потоку, и к нему можно обратиться через свойство Thread.CurrentPrincipal. Контекст безопасности содержит связанный с ним объект Identity, с информацией о пользователе. Если пользователь прошел аутентификацию, свойство Identity.IsAuthenticated вернет значение true. Для анонимных запросов свойство вернет false.

Использование HTTP обработчиков сообщений для аутентификации.

Вместо использования хоста, логику аутентификации можно поместить в обработчик HTTP сообщения. В этом случае, обработчик сообщения исследует HTTP запрос и сам задаст контекст безопасности.

Несколько примеров для чего может понадобиться аутентификация в обработчиках сообщений:

HTTP модуль видит все запросы проходящие по каналу ASP.NET, обработчик видит только запросы предназначенные WebAPI
Вы можете установить отдельные обработчики сообщений на каждый маршрут, применяя различные схемы аутентификации
HTTP модули специфичны для IIS. Обработчики сообщений независимы от хоста, и могут быть использованы как в случае web-хостинга, так и при self-хостинге.
HTTP модули учавствуют при логгинге IIS, аудите и т.д.
HTTP модули запускаются раньше в цепочке прохождения запроса. Если проводите аутентификацию в обработчике сообщений, контекст безопасности не будет установлен пока не будет запущен обработчик. Кроме того, контекст безопасности возвращается к предыдущему состоянию когда ответ на запрос покинет обработчик сообщения.

В общем, если вы не собираетесь использовать self-хостинг, использование HTTP модулей аутентификации лучший вариант. В противном случае логику стоит вынести в обработчики сообщений.

Установка контекста безопасности

Если ваше приложение выполняет какую-либо логику связанную с аутентификацией, вы должны задать контекст безопасности в двух свойствах:

Thread.CurrentPrincipal - стандартный путь задать контекст безопасности для потока в.NET
HttpContext.Current.User - свойство специфичное для ASP.NET

Следующий код показывает как задать контекст безопасности:

Private void SetPrincipal(IPrincipal principal) { Thread.CurrentPrincipal = principal; if (HttpContext.Current != null) { HttpContext.Current.User = principal; } }

Для веб-хостинга, вы должны задать контекст безопасности в обоих свойствах, иначе контекст безопасности может стать несогласованным. Для обеспечения независимости вашего кода от способа хостинга , следует выставлять проверку на null для свойства HttpContext.Current, как показано в коде. В случае self-хостинга, его значение будет null и задавать контекст безопасности не требуется.

Авторизация

Фильтры авторизации отрабатывают до методов контроллера. Если запрос не авторизован, фильтр вернет сообщение об ошибке, а метод контроллера не будет вызван.
В методе контроллера вы можете получить текущий контекст безопасности из свойства ApiController.User. Например, вы можете фильтровать список ресурсов в зависимости от имени пользователя, возвращая только доступные для него.

Использование аттрибута

WebAPI предоставляет встроенный фильтр авторизации, AuthorizeAttribute, этот фильтр проверяет авторизован ли пользователь. Если нет, фильтр вернет код состояния HTTP 401 (Не авторизован), без вызова метода.
Вы можете применять фильтр как глобально, так и на уровне контроллера или на уровне методов.

Фильтр на глобальном уровне : чтобы ограничить доступ для каждого контроллера WebAPI, добавьте фильтр AuthorizeAttribute в глобальный список фильтров:

Public static void Register(HttpConfiguration config) { config.Filters.Add(new AuthorizeAttribute()); }

Фильтр на уровне контроллера : для ограничения доступа к конкретному контроллеру, добавьте фильтр в качестве атрибута класса контроллера:

// Require authorization for all actions on the controller. public class ValuesController: ApiController { public HttpResponseMessage Get(int id) { ... } public HttpResponseMessage Post() { ... } }

Фильтр на уровне метода : для ограничения доступа к методу, добавьте к нему атрибут:

Public class ValuesController: ApiController { public HttpResponseMessage Get() { ... } // Require authorization for a specific action. public HttpResponseMessage Post() { ... } }

Кроме того, в можете задать ограничение на контроллер, и разрешить анонимный доступ на отдельные методы при помощи атрибута . В следующем примере, доступ к методу Post ограничен, а метод Get доступен для анонимных вызовов:

Public class ValuesController: ApiController { public HttpResponseMessage Get() { ... } public HttpResponseMessage Post() { ... } }

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

// Restrict by user: public class ValuesController: ApiController { } // Restrict by role: public class ValuesController: ApiController { }

Фильтр AuthorizeAttribute для контроллеров WebAPI находится в пространстве имен System.Web.Http. Существует аналогичный фильтр для контроллеров MVC в пространстве имен System.Web.Mvc. Этот тип несовместим с контроллерами WebAPI.

Кастомные фильтр авторизации

Кастомный фильтр должен быть унаследован от одного из следующих типов:

AuthorizeAttribute . Наследуйте этот класс для реализации синхронной логики авторизации на основе текущего пользователя или роли пользователя.
AuthorizationFilterAttribute . Данный класс пригодится для реализации логики авторизации необязательно основанной на пользователе или его роли.
IAuthorizationFilter . Реализуйте этот интерфейс для асинхронной логики авторизации. Например ваша авторизация предполагает асинхронные или сетевые вызовы (если логика завязана на процессорных вычислениях, то лучше наследоваться от AuthorizationFilterAttribute, чтобы не писать асинхронные методы)

Следующая диаграмма показывает иерархию классов фильтров:

Авторизация внутри метода контроллера

В некоторых случаях можно разрешить выполнение запроса, но изменить поведение на основе контекста безопасности. Например, результат запроса зависит от роли пользователя. Внутри метода контроллера вы можете получить текущий контекст безопасности обратившись к свойству ApiController.User:

Public HttpResponseMessage Get() { if (User.IsInRole("Administrators")) { // ... } }

* Перевод выполнен в вольном стиле, возможно кого-то покоробят англицизмы наподобие "кастомный", но эти слова стали частью it жаргона, и русский перевод не воспринимается как должно.

Tutorial

Цель урока : Изучить способ авторизации через Cookie, использование стандартных атрибутов доступа к контроллеру и методу контроллера. Использование IPrincipal. Создание собственного модуля (IHttpModule) и собственного фильтра IActionFilter.

Небольшое отступление: На самом деле в asp.net mvc все учебники рекомендуют пользоваться уже придуманной системой авторизации, которая называется AspNetMembershipProvider, она была описана в статье http://habrahabr.ru/post/142711/ (сейчас доступ уже закрыт), но обьяснено это с точки зрения «нажимай и не понимай, что там внутри». При первом знакомстве с asp.net mvc меня это смутило. Далее, в этой статье http://habrahabr.ru/post/143024/ - сказано, что пользоваться этим провайдером – нельзя. И я согласен с этим. Здесь же, мы достаточно глубоко изучаем всякие хитрые asp.net mvc стандартные приемы, так что это один из основных уроков.

Кукисы

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

Сервер в заголовок ответа пишет:
Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
Например:

HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value Set-Cookie: name2=value2; Expires=Wed, 09-Jun-2021 10:18:14 GMT
Браузер (если не истекло время действия кукиса) при каждом запросе:
GET /spec.html HTTP/1.1 Host: www.example.org Cookie: name=value; name2=value2 Accept: */*

Устанавливаем cookie (/Areas/Default/Controllers/HomeController.cs):
public ActionResult Index() { var cookie = new HttpCookie() { Name ="test_cookie", Value = DateTime.Now.ToString("dd.MM.yyyy"), Expires = DateTime.Now.AddMinutes(10), }; Response.SetCookie(cookie); return View(); }

В Chrome проверяем установку:

Для получения кукисов:
var cookie = Request.Cookies["test_cookie"];

Делаем точку остановки и проверяем:

Примечание: подробнее можно изучить кукисы по следующей ссылке:
http://www.nczonline.net/blog/2009/05/05/http-cookies-explained/

Авторизация

В нашем случае авторизация будет основана на использовании кукисов. Для этого изучим следующие положения:

FormsAuthenticationTicket – мы воспользуемся этим классом, чтобы хранить данные авторизации в зашифрованном виде
Нужно реализовать интерфейс IPrincipal и установить в HttpContext.User для проверки ролей и IIdentity интерфейса.
Для интерфейса IIdentity сделать реализацию
Вывести в BaseController в свойство CurrentUser значение пользователя, который сейчас залогинен.

Приступим.
Создадим интерфейс IAuthentication и его реализацию CustomAuthentication (/Global/Auth/IAuthentication.cs):

Public interface IAuthentication { ///

/// Конекст (тут мы получаем доступ к запросу и кукисам) ///

HttpContext HttpContext { get; set; } User Login(string login, string password, bool isPersistent); User Login(string login); void LogOut(); IPrincipal CurrentUser { get; } }

Реализация (/Global/Auth/CustomAuthentication.cs):
public class CustomAuthentication: IAuthentication { private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger(); private const string cookieName = "__AUTH_COOKIE"; public HttpContext HttpContext { get; set; } public IRepository Repository { get; set; } #region IAuthentication Members public User Login(string userName, string Password, bool isPersistent) { User retUser = Repository.Login(userName, Password); if (retUser != null) { CreateCookie(userName, isPersistent); } return retUser; } public User Login(string userName) { User retUser = Repository.Users.FirstOrDefault(p => string.Compare(p.Email, userName, true) == 0); if (retUser != null) { CreateCookie(userName); } return retUser; } private void CreateCookie(string userName, bool isPersistent = false) { var ticket = new FormsAuthenticationTicket(1, userName, DateTime.Now, DateTime.Now.Add(FormsAuthentication.Timeout), isPersistent, string.Empty, FormsAuthentication.FormsCookiePath); // Encrypt the ticket. var encTicket = FormsAuthentication.Encrypt(ticket); // Create the cookie. var AuthCookie = new HttpCookie(cookieName) { Value = encTicket, Expires = DateTime.Now.Add(FormsAuthentication.Timeout) }; HttpContext.Response.Cookies.Set(AuthCookie); } public void LogOut() { var httpCookie = HttpContext.Response.Cookies; if (httpCookie != null) { httpCookie.Value = string.Empty; } } private IPrincipal _currentUser; public IPrincipal CurrentUser { get { if (_currentUser == null) { try { HttpCookie authCookie = HttpContext.Request.Cookies.Get(cookieName); if (authCookie != null && !string.IsNullOrEmpty(authCookie.Value)) { var ticket = FormsAuthentication.Decrypt(authCookie.Value); _currentUser = new UserProvider(ticket.Name, Repository); } else { _currentUser = new UserProvider(null, null); } } catch (Exception ex) { logger.Error("Failed authentication: " + ex.Message); _currentUser = new UserProvider(null, null); } } return _currentUser; } } #endregion }

Суть сводится к следующему, мы, при инициализации запроса, получаем доступ к HttpContext.Request.Cookies и инициализируем UserProvider:

Var ticket = FormsAuthentication.Decrypt(authCookie.Value); _currentUser = new UserProvider(ticket.Name, Repository);

Для авторизации в IRepository добавлен новый метод IRepository.Login. Реализация в SqlRepository:
public User Login(string email, string password) { return Db.Users.FirstOrDefault(p => string.Compare(p.Email, email, true) == 0 && p.Password == password); }

UserProvider, собственно, реализует интерфейс IPrincipal (в котором есть проверка ролей и доступ к IIdentity).
Рассмотрим класс UserProvider (/Global/Auth/UserProvider.cs):

Public class UserProvider: IPrincipal { private UserIndentity userIdentity { get; set; } #region IPrincipal Members public IIdentity Identity { get { return userIdentity; } } public bool IsInRole(string role) { if (userIdentity.User == null) { return false; } return userIdentity.User.InRoles(role); } #endregion public UserProvider(string name, IRepository repository) { userIdentity = new UserIndentity(); userIdentity.Init(name, repository); } public override string ToString() { return userIdentity.Name; }

Наш UserProvider знает про то, что его IIdentity классом есть UserIdentity , а поэтому знает про класс User , внутри которого мы реализуем метод InRoles(role) :

Public bool InRoles(string roles) { if (string.IsNullOrWhiteSpace(roles)) { return false; } var rolesArray = roles.Split(new { "," }, StringSplitOptions.RemoveEmptyEntries); foreach (var role in rolesArray) { var hasRole = UserRoles.Any(p => string.Compare(p.Role.Code, role, true) == 0); if (hasRole) { return true; } } return false; }

В метод InRoles мы ожидаем, что придет запрос о ролях, которые допущены к ресурсу, разделенные запятой. Т.е., например, “admin,moderator,editor”, если хотя бы одна из ролей есть у нашего User – то возвращаем зачение «истина» (доступ есть). Сравниваем по полю Role.Code, а не Role.Name.
Рассмотрим класс UserIdentity (/Global/Auth/UserIdentity.cs):
public class UserIndentity: IIdentity { public User User { get; set; } public string AuthenticationType { get { return typeof(User).ToString(); } } public bool IsAuthenticated { get { return User != null; } } public string Name { get { if (User != null) { return User.Email; } //иначе аноним return "anonym"; } } public void Init(string email, IRepository repository) { if (!string.IsNullOrEmpty(email)) { User = repository.GetUser(email); } } }
В IRepository добавляем новый метод GetUser(email) . Реализация для SqlRepository.GetUser() (LessonProject.Model:/SqlRepository/User.cs):

Public User GetUser(string email) { return Db.Users.FirstOrDefault(p => string.Compare(p.Email, email, true) == 0); }

Почти все готово. Выведем CurrentUser в BaseController:
public IAuthentication Auth { get; set; } public User CurrentUser { get { return ((UserIndentity)Auth.CurrentUser.Identity).User; } }

Да, это не очень правильно, так как здесь присутствует сильное связывание. Поэтому сделаем так, введем еще один интерфейс IUserProvider , из которого мы будем требовать вернуть нам авторизованного User:
public interface IUserProvider { User User { get; set; } } … public class UserIndentity: IIdentity, IUserProvider { ///

/// Текщий пользователь ///

public User User { get; set; } … public IAuthentication Auth { get; set; } public User CurrentUser { get { return ((IUserProvider)Auth.CurrentUser.Identity).User; } }
А теперь попробуем инициализировать это всё.
Вначале добавим наш IAuthentication + CustomAuthentication в регистрацию к Ninject (/App_Start/NinjectWebCommon.cs):

Kernel.Bind().To().InRequestScope();

Потом создадим модуль, который будет на событие AuthenticateRequest совершать действие авторизации:
public class AuthHttpModule: IHttpModule { public void Init(HttpApplication context) { context.AuthenticateRequest += new EventHandler(this.Authenticate); } private void Authenticate(Object source, EventArgs e) { HttpApplication app = (HttpApplication)source; HttpContext context = app.Context; var auth = DependencyResolver.Current.GetService(); auth.HttpContext = context; context.User = auth.CurrentUser; } public void Dispose() { } }

Вся соль в строках: auth.HttpContext = context и context.User = auth.CurrentUser . Как только наш модуль авторизации узнает о контексте и содержащихся в нем кукисах, ту же моментально получает доступ к имени, по нему он в репозитории получает данныепользователя и возвращает в BaseController. Но не сразу всё, а по требованию.
Подключаем модуль в Web.config:
…

План таков:

Наверху показываем, авторизован пользователь или нет. Если авторизован, то его email и ссылка на выход, если нет, то ссылки на вход и регистрацию
Создаем форму для входа
Если пользователь правильно ввел данные – то авторизуем его и отправляем на главную страницу
Если пользователь выходит – то убиваем его авторизацию

Поехали. Добавляем Html.Action(“UserLogin”, “Home”) – это partial view (т.е. кусок кода, который не имеет Layout) – т.е. выводится где прописан, а не в RenderBody().
_Layout.cshtml (/Areas/Default/Views/Shared/_Layout.cshtml):

@RenderBody() HomeController.cs: public ActionResult UserLogin() { return View(CurrentUser); }

UserLogin.cshtml (/Areas/Default/Views/Home/UserLogin.cshtml):

@model LessonProject.Model.User @if (Model != null) {

@Model.Email

@Html.ActionLink("Выход", "Logout", "Login")

} else {

@Html.ActionLink("Вход", "Index", "Login")

@Html.ActionLink("Регистрация", "Register", "User")

}

Контроллер входа выхода LoginController (/Areas/Default/Controllers/LoginController.cs):

Public class LoginController: DefaultController { public ActionResult Index() { return View(new LoginView()); } public ActionResult Index(LoginView loginView) { if (ModelState.IsValid) { var user = Auth.Login(loginView.Email, loginView.Password, loginView.IsPersistent); if (user != null) { return RedirectToAction("Index", "Home"); } ModelState["Password"].Errors.Add("Пароли не совпадают"); } return View(loginView); } public ActionResult Logout() { Auth.LogOut(); return RedirectToAction("Index", "Home"); } }

LoginView.cs (/Models/ViewModels/LoginView.cs):
public class LoginView { public string Email { get; set; } public string Password { get; set; } public bool IsPersistent { get; set; } }

Страница для входа Index.cshtml (/Areas/Default/Views/Index.cshtml):

@model LessonProject.Models.ViewModels.LoginView @{ ViewBag.Title = "Вход"; Layout = "~/Areas/Default/Views/Shared/_Layout.cshtml"; }

Вход

@using (Html.BeginForm("Index", "Login", FormMethod.Post, new { @class = "form-horizontal" })) {

Вход

@Html.TextBox("Email", Model.Email, new { @class = "input-xlarge" })

Введите Email

@Html.ValidationMessage("Email")

Пароль

@Html.Password("Password", Model.Password, new { @class = "input-xlarge" }) @Html.ValidationMessage("Password")

}

Запускаем и проверяем:

Все исходники находятся по адресу

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

Авторизация - это процесс определения того, имеет ли аутентифицированный пользователь достаточные привилегии на выполнение того или иного действия. Таким действием может быть запрос веб-страницы, доступ к ресурсу, управляемому операционной системой (такому как файл или база данных), либо выполнение специфичных для приложения задач (наподобие размещения заказа в системе управления заказами или назначения проекта в приложении управления проектами вроде Microsoft Project Server).

Некоторые из этих проверок Windows осуществляет автоматически, а другие можно кодировать декларативно, используя файл web.config. Но некоторые проверки придется выполнять непосредственно в коде с использованием объекта IPrincipal.

Авторизация URL

Самый простой способ установки прав доступа предусматривает их установку на индивидуальных веб-страницах, веб-службах и подкаталогах. В идеале платформа веб-приложений должна поддерживать специфичную к ресурсам авторизацию без необходимости изменения кода и перекомпиляции приложения. ASP.NET поддерживает это требование с помощью декларативных правил авторизации, которые можно определять в файле web.config.

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

Авторизация такого типа называется авторизацией URL, потому что принимает во внимание только две детали - контекст безопасности пользователя и URL ресурса, к которому пользователь пытается обратиться. Если доступ к странице запрещен и применяется аутентификация с помощью форм, то пользователь будет перенаправлен на страницу регистрации.

Правила авторизации

Другими словами, существуют два типа правил: разрешить (allow) и запретить (deny). Тех и других можно добавлять столько угодно. Каждое правило идентифицирует одного или более пользователей либо ролей (групп пользователей). Вдобавок можно использовать атрибут verbs, чтобы создавать правила, применимые только к специфичным типам HTTP-запросов (GET, POST, HEAD ИЛИ DEBUG).

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

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

Можно использовать дополнительный шаблонный символ - звездочку (*), которая представляет всех пользователей. Например, следующий раздел открывает доступ аутентифицированным и анонимным пользователям:

Такое правило требуется редко, потому что оно уже присутствует в файле machine.config. После того как среда ASP.NET применит все правила из файла web.config, она применяет правила из machine.config. В результате любому пользователю, кому явно закрыт доступ, автоматически его получает.

Теперь посмотрим, что произойдет, если в раздел добавить более одного правила:

При оценке правил среда ASP.NET сканирует список сверху вниз. Как только она обнаружит применимое правило, поиск прекращается. Поэтому в предыдущем случае она определит, что правило применимо к текущему запросу и не станет принимать во внимание вторую строку. В результате это правило разрешит доступ всем пользователям. Однако если две строки поменять местами, то доступ будет закрыт анонимным пользователям (согласно правилу в первой строке) и разрешен всем остальным (согласно правилу во второй строке).

Когда правила авторизации добавляются в файл web.config корневого каталога веб-приложения, они автоматически применяются ко всем веб-ресурсам, которые являются частью приложения. Если вход анонимным пользователям запрещен, ASP.NET проверит метод аутентификации. Если выбрана аутентификация с помощью форм, ASP.NET перенаправит пользователя на страницу регистрации.

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

Конфигурирование доступа для определенных пользователей

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

Например, следующее правило авторизации специально ограничивает доступ для трех пользователей. Эти пользователи не смогут обратиться к страницам, которые находятся в каталоге с файлом web.config, содержащим эти вхождения. Все остальные аутентифицированные пользователи обращаться к этим страницам смогут:

Можно также определить список имен, разделенный запятыми, и запретить доступ сразу нескольким пользователям. Ниже показана версия, эквивалентная предыдущему примеру, в которой используются только два правила аутентификации:

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

Создавая безопасные приложения, часто лучше явно разрешить доступ определенным пользователям и группам, а затем запретить всем остальным (вместо запрета доступа определенным пользователям, как в предыдущих примерах). Ниже приведен пример правил авторизации, которые явно открывают доступ двум пользователям. Запросы всех прочих пользователей не будут удовлетворены, даже несмотря на то, что они аутентифицированы:

Следует обратить внимание на одну деталь. Формат имен пользователей в этих примерах предполагает аутентификацию с помощью форм. При такой аутентификации имя пользователя назначается при вызове метода RedirectFromLoginPage(). В этой точке UrlAuthorizationModule также использует это имя и проверит его по списку правил авторизации.

Контроль доступа к определенным каталогам

Общепринятое проектное решение для приложения предусматривает размещение файлов, которые требуют аутентификации, в отдельном каталоге. Благодаря конфигурационным файлам ASP.NET, этот подход реализуется просто. Оставьте элемент

Вспомните, что когда вы добавляете файл web.config в подкаталог, он не должен содержать никаких других специфичных для приложения настроек. Фактически он должен содержать только информацию авторизации, как показано ниже:

Настройки дескриптора в файле web.config подкаталога приложения изменять нельзя. Вместо этого все каталоги в приложении должны использовать одну и ту же систему аутентификации. Однако каждый каталог может иметь собственный набор правил авторизации.

При использовании правил авторизации в подкаталоге среда ASP.NET все равно читает правила авторизации из родительского каталога. Отличие в том, что правила из подкаталога применяются первыми. Это важно, потому что ASP.NET останавливается, как только находит соответствие правила авторизации. Рассмотрим пример, в котором корневой виртуальный каталог содержит одно правило:

а подкаталог - другое правило:

В этом случае пользователь dan сможет получить доступ к любому ресурсу корневого каталога, но не получит никакого доступа к ресурсам из подкаталога. Если же вы поменяете местами эти два правила, то dan получит доступ только к ресурсам подкаталога, но не получит доступа к ресурсам корневого каталога.

Более интересно то, что ASP.NET допускает неограниченную иерархию подкаталогов и правил авторизации. Например, вполне возможно иметь виртуальный каталог с правилами авторизации, подкаталог, определяющий дополнительные права, и еще один подкаталог внутри этого подкаталога, в котором определен свой набор правил. Проще всего понять процесс авторизации в этом случае - представить все правила в виде единого списка, начинающегося с каталога, в котором находится запрошенная страница. Если все эти правила обработаны и соответствие не найдено, ASP.NET начинает читать правила авторизации из родительского каталога, затем из каталога, родительского по отношению к этому, и т.д. - до тех пор, пока соответствие не будет найдено. Если никаких подходящих правил не найдено, ASP.NET в конечном итоге применяет правило из файла machine.config.

Контроль доступа к определенным файлам

Обычно установка прав доступа к файлам на уровне каталога - самый ясный и легкий подход. Однако существует возможность ограничить доступ к определенным файлам за счет добавления дескрипторов в файл web.config.

Дескрипторы location размещаются вне главного дескриптора и вложены непосредственно в базовый дескриптор , как показано ниже:

В этом примере открывается доступ ко всем файлам приложения за исключением SecuredPage.aspx и AnotherSecuredPage.aspx, которые имеют правило авторизации, запрещающее анонимный доступ к ним.

Конфигурирование доступа для определенных ролей

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

Сама по себе аутентификация с помощью форм роли не поддерживает, но наряду с Membership API в ASP.NET доступен интерфейс API Roles , который представляет собой готовую к использованию реализацию поддержки и управления ролями для приложений. Кроме того, если вы не хотите использовать эту инфраструктуру, достаточно легко создать собственную, которая разделит пользователей на соответствующие группы на основе их удостоверений.

После определения для ролей можно создавать правила авторизации. Фактически эти правила выглядят точно так же, как показанные ранее правила, специфичные для пользователей. Например, следующие правила авторизации запрещают доступ анонимным пользователям, разрешая его двум конкретным пользователям (dan и alex) и двум группам (Manager и Supervisor). Доступ всем прочим пользователям запрещен:

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

Рассмотрим пример:

Ниже описано, как ASP.NET разбирает эти правила:

В этом примере доступ пользователю alex будет разрешен независимо от групп, к которым он принадлежит.

Всем пользователям из роли Guest доступ будет закрыт. Если alex входит в Guest, доступ ему остается открытым, потому что специфичное для пользователя правило найдено первым.

Далее всем пользователям из группы Manager доступ открыт. Единственным исключением будут те, что входят и в группу Manager и в Guest. Правило Guest определено раньше в списке, поэтому данным пользователям вход уже закрыт.

Затем доступ закрывается пользователю dan. Но если dan входит в группу Manager, доступ для него остается открытым.

Любым пользователям, относящимся к группе Supervisor, кроме тех, доступ для которых был открыт или закрыт предыдущими правилами, доступ открывается.

И, наконец, для всех прочих пользователей доступ закрыт.

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

Файловая авторизация

Авторизация на основе URL - один из краеугольных камней авторизации ASP.NET. Однако в ASP.NET также используется другой тип авторизации, который часто пропускается или игнорируется многими разработчиками. Это авторизация на основе файлов, реализуемая модулем FileAuthorizationModule . Авторизация на основе файлов работает, только в случае применения Windows-аутентификации. Если же используется специальная аутентификация или аутентификация с помощью форм, файловая авторизация не применяется.

Чтобы понять суть файловой авторизации, необходимо разобраться, как операционная система Windows обеспечивает безопасность файловой системы. В случае файловой системы NTFS можно установить списки ACL (access control list - список контроля доступа) , указывающие идентичность пользователей и ролей, которым открыт или запрещен доступ к индивидуальным файлам. Модуль FileAuthorizationModule просто проверяет права доступа к запрошенному файлу, определенные Windows.

Например, если запрашивается веб-страница, FileAuthorizationModule проверяет, имеет ли текущий аутентифицированный IIS пользователь права доступа к соответствующему файлу.aspx. Если не имеет, то код страницы не выполняется и пользователь получает сообщение о запрете доступа.

Новые пользователи ASP.NET часто удивляются, почему файловая авторизация должна быть реализована отдельным модулем, и почему бы ни положиться в этом на операционную систему?

Чтобы понять необходимость в модуле FileAuthorizationModule, необходимо вспомнить, как ASP.NET выполняет код. Если не включено заимствование прав, ASP.NET выполняется от имени фиксированного пользовательской учетной записи, такой как ASPNET. Операционная система Windows будет проверять, имеет ли учетная запись ASPNET права, необходимые для доступа к файлу.aspx, но она не выполнит ту же проверку для пользователя, аутентифицированного IIS. Модуль FileAuthorizationModule заполняет этот пробел. Он осуществляет проверку авторизации с учетом контекста безопасности текущего пользователя. В результате системный администратор может устанавливать права доступа к файлам или папкам и контролировать доступ к частям приложения ASPNET. Обычно проще и удобнее использовать правила авторизации в файле web.config. Однако если необходимо воспользоваться преимуществами существующих привилегий Windows в локальной или корпоративной сети, то это можно сделать.

Предоставление каждому посетителю сайта уникальной учётной записи позволяет вам однозначно идентифицировать любого из них. Идентификация позволяет веб-сайту менять оформление и контент в зависимости от предпочтений и интересов посетителей.

Многие современные сайты содержат различные разделы, предназначенные для разных групп пользователей: от обычных посетителей до администраторов. Также вы можете использовать авторизацию пользователей для предоставления им доступа к различным ресурсам на персональной основе.

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

Также современные веб-сайты могут иметь различные настройки, одни из которых предназначены для удобства широкого круга пользователей, в то время как другие рассчитаны только на использование веб-мастерами. Авторизация позволяет определить, какие функции сайта необходимы и достаточны для каждого конкретного пользователя.

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

Такие функции, как заказ товаров, корректировка заказов и отслеживание доставки должны быть доступны только зарегистрированным пользователям. И вы уж точно не захотите, чтобы те или другие могли просматривать или менять заказы, сделанные другими пользователями.

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

Что такое авторизация?

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

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

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

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

Аутентификация сама по себе позволяет разработчику использовать многие полезные функции и настроить сайт согласно предпочтениям каждого конкретного пользователя.

Авторизация же использует уникальный идентификатор пользователя для того, чтобы определить, какие действия пользователь имеет право совершить на сайте: какие страницы просмотреть, какие данные изменить и т. д.

Управление доступом на основе групп и ролей

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

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

Новый пользователь на сайте включается в какую-либо группу. Это может делаться автоматически либо вручную, администратором сайта. Таким образом, пользователь получает заранее определённый набор прав и ограничений.

Чтобы отразить изменение политики безопасности сайта на всех имеющихся и будущих пользователях, администратору достаточно откорректировать свойства группы.

Однако в случае принадлежности пользователя к нескольким группам или ролям в системе должен быть предусмотрен механизм решения конфликтов прав. Например, пользователь блога может быть включён в две группы, одной из которых разрешено создавать посты, а другой – только просматривать. Какое право присваивать пользователю в итоге?

Большая часть систем оставляет в действии минимальные права либо предусматривает приоритет запретов над разрешениями. В таком случае наш гипотетический пользователь не будет иметь права писать в блог, так как ограничение полномочий будет преобладать над разрешением.

Хорошей практикой является разделение пользователей на группы по виду деятельности на сайте. Например, наш блог может иметь следующие группы пользователей: «Авторы », «Редакторы », «Модераторы » и т.д.

Альтернативный подход будет состоять в том, чтобы выделить группы «Создание статей », «Правка статей », «Удаление комментариев » и т. д. Такой подход будет обладать значительной гибкостью, но при этом придётся поддерживать на сайте большее количество различных групп.

Защита страниц средствами ASP.NET

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

При защите сайта на ASP.NET используются три направления разделения доступа:

Система роутинга адресов;
Веб-формы (файлы и папки );
Структуры MVC .

Защита сайта на веб-формах

Как веб-формы, так и роутинг в ASP.NET использует для защиты доступа web.config . Основа конфигурации для защиты доступа к ресурсам сайта выглядит примерно так:

XML -элемент location определяет путь к защищаемому ресурсу: папке, странице или элементу роутинга. В данном примере он задаёт страницу adminhome.aspx . Можно защитить содержимое папки целиком, указав путь к ней. Если атрибут path отсутствует, настройки безопасности применяются к той папке, в которой находится файл web.config , со всеми её подпапками.

Элемент authorization определяет, кто имеет или не имеет доступа к защищаемому ресурсу. Права проверяются последовательно, начиная с первого и до тех пор, пока совпадение не будет найдено. Вложенный элемент allow задаёт разрешение, а deny – запрещение доступа к ресурсу для заданного пользователя или роли.

В нашем примере правило будет проверено первым. Если пользователь обладает ролью администратора, доступ ему будет предоставлен, и проверка условий на этом прекратится.

В противном случае проверка продолжится до следующего правила: , которое лишит доступа к ресурсу всех пользователей. Таким образом, наш пример даёт доступ к файлу только администраторам. Всем остальным будет отказано в доступе.

Существует несколько специальных символов, обозначающих часто используемые группы. Мы уже видели символ «* », обозначающий всех пользователей.

Символ «? » обозначает анонимного (не успевшего зарегистрироваться ) пользователя. Несколько групп или отдельных пользователей могут быть перечислены через запятую. Пользователи и роли могут смешиваться в одном правиле, например:

Защита MVC-сайта

Разработка сайта согласно методологии MVC сосредотачивается не на файлах и папках, а на контроллерах и их действиях. Соответствующим образом меняется и защита. По умолчанию все действия всех контроллеров доступны всем пользователям, как и в случае с веб-формами. Вам доступны те же пользователи и роли, но файлов web.config больше нет.

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

Public class AdminController: Controller { ...

Для обозначения анонимов и всех пользователей доступны те же символы «? » и «* ». Вы можете применять установки ко всему контроллеру или к отдельным действиям. При этом настройки действий будут иметь более высокий приоритет, чем настройки всего контроллера:

Public ActionResult AdminView() { ...

Если вы не укажете пользователей или ролей в атрибуте , то доступ будет разрешён всем зарегистрированным пользователям.

В ASP.NET 4 был добавлен атрибут , который позволил разрешить анонимному пользователю доступ к отдельным действиям защищённого контроллера.

Управление контентом в зависимости от роли

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

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

Например, не имеет смысла показывать ссылку на панель администрирования рядовым пользователям. Клиент, не имеющий отправленных заказов, не должен видеть кнопку трекинга. Даже если элемент не активен или ведёт на страницу авторизации, он может смутить простого пользователя и дать злоумышленнику пищу для размышления.

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

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

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

Всегда проверяйте, насколько безопасен код, обрабатывающий GET -запросы. Например, ваш веб-магазин имеет запрос для удаления заказа:

UpdateOrder.aspx?order=33&action=delete

Теперь, представьте хакера, удаляющего все заказы перебором параметра order . Проверяется ли принадлежность заказа пользователю в соответствующем обработчике?

В другом случае отсутствие проверки в чём-то вроде:

UpdateOrder.aspx?order=33&action=refund

позволит злоумышленнику получить возмещение за чужой или не оплаченный заказ. Никогда не полагайтесь на скрытие ссылок как единственный механизм защиты от не авторизованного доступа.

Аспекты безопасности пользовательских сессий

Защита самих данных авторизации является отдельной задачей безопасности, хоть и близко соотносящейся с безопасностью доступа к ресурсам и коду. Во-первых, на безопасность механизма аутентификации влияет продолжительность сессии. В ASP.NET этот параметр задаётся в web.config следующим образом:

В этом примере время жизни сессии составит 30 минут. Атрибут slidingExpiration определяет, сбрасывает ли счётчик истечения сессии поступление запроса от пользователя. Если установить данному атрибуту значение false , пользователю придётся осуществлять вход каждые 30 минут, даже во время активной работы с сайтом.

Также необходимо учитывать возможность кражи сессии. Большинство веб-фреймворков хранят идентификатор сессии в маленьком кусочке текстовых данных, называемом кукой или печенькой (cookie ), в браузере пользователя.

Если кука никак не защищена, её может использовать злоумышленник, перехватив трафик легитимного пользователя и представившись системе этим пользователем.