Ескертпе
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Жүйеге кіруді немесе каталогтарды өзгертуді байқап көруге болады.
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Каталогтарды өзгертуді байқап көруге болады.
HTTP поддерживает использование нескольких механизмов проверки подлинности для управления доступом к ресурсам. Обычная проверка подлинности предоставляет доступ к ресурсам только тем клиентам, у которых есть правильные учетные данные. В этой статье показано, как использовать базовую проверку подлинности для защиты доступа к ресурсам веб-службы RESTful.
Примечание.
В iOS 9 и более поздней версии безопасность транспорта приложений (ATS) обеспечивает безопасные подключения между интернет-ресурсами (например, сервером приложения) и приложением, тем самым предотвращая случайное раскрытие конфиденциальной информации. Так как ATS включен по умолчанию в приложениях, созданных для iOS 9, все подключения будут соответствовать требованиям безопасности ATS. Если подключения не соответствуют этим требованиям, они завершаются сбоем с исключением.
ATS можно отказаться от использования протокола и безопасного HTTPS обмена данными для интернет-ресурсов. Это можно сделать, обновив файл Info.plist приложения. Дополнительные сведения см. в разделе "Безопасность транспорта приложений".
Проверка подлинности пользователей по протоколу HTTP
Обычная проверка подлинности — это самый простой механизм проверки подлинности, поддерживаемый HTTP, и включает в себя клиент, отправляющий имя пользователя и пароль в виде незашифрованного текста в кодировке Base64. Процесс создания моментальных снимков хранилища состоит из следующих этапов:
- Если веб-служба получает запрос на защищенный ресурс, он отклоняет запрос с кодом состояния HTTP 401 (доступ запрещен) и задает заголовок ответа WWW-Authenticate, как показано на следующей схеме:

- Если веб-служба получает запрос на защищенный ресурс с
Authorizationправильным заголовоком, веб-служба отвечает с кодом состояния HTTP 200, который указывает, что запрос выполнен успешно и что запрошенные сведения отображаются в ответе. Этот сценарий показан на следующей схеме:

Примечание.
Обычная проверка подлинности должна использоваться только для подключения HTTPS. При использовании по протоколу HTTP-подключения заголовок можно легко декодировать, Authorization если HTTP-трафик фиксируется злоумышленником.
Указание базовой проверки подлинности в веб-запросе
Использование базовой проверки подлинности указывается следующим образом:
- Строка "Basic" добавляется в
Authorizationзаголовок запроса. - Имя пользователя и пароль объединяются в строку с форматом "имя_пользователя:password", который затем закодирован и добавлен в
Authorizationзаголовок запроса.
Поэтому при использовании имени пользователя XamarinUser и пароля XamarinPassword заголовок становится следующим:
Authorization: Basic WGFtYXJpblVzZXI6WGFtYXJpblBhc3N3b3Jk
Класс HttpClient может задать значение заголовка AuthorizationHttpClient.DefaultRequestHeaders.Authorization для свойства. HttpClient Так как экземпляр существует в нескольких запросах, Authorization заголовок должен быть задан только один раз, а не при выполнении каждого запроса, как показано в следующем примере кода:
public class RestService : IRestService
{
HttpClient _client;
...
public RestService ()
{
var authData = string.Format ("{0}:{1}", Constants.Username, Constants.Password);
var authHeaderValue = Convert.ToBase64String (Encoding.UTF8.GetBytes (authData));
_client = new HttpClient ();
_client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue ("Basic", authHeaderValue);
}
...
}
Затем, когда запрос выполняется в операцию веб-службы, запрос подписывается Authorization заголовком, указывая, имеет ли пользователь разрешение на вызов операции.
Внимание
Хотя этот код сохраняет учетные данные в виде констант, они не должны храниться в небезопасном формате в опубликованном приложении.
Обработка сервера заголовков авторизации
Служба REST должна декорировать каждое действие атрибутом [BasicAuthentication] . Этот атрибут используется для анализа Authorization заголовка и определения допустимости учетных данных в кодировке Base64, сравнивая их со значениями, хранящимися в web.config. Хотя этот подход подходит для примера службы, он требует расширения для общедоступной веб-службы.
В базовом модуле проверки подлинности, используемом службами IIS, пользователи проходят проверку подлинности в учетных данных Windows. Таким образом, пользователи должны иметь учетные записи в домене сервера. Однако модель базовой проверки подлинности может быть настроена, чтобы разрешить пользовательскую проверку подлинности, где учетные записи пользователей проходят проверку подлинности в внешнем источнике, например в базе данных. Дополнительные сведения см. в разделе "Базовая проверка подлинности" в веб-API ASP.NET на веб-сайте ASP.NET.
Примечание.
Обычная проверка подлинности не предназначена для управления выходом из системы. Поэтому стандартный базовый подход проверки подлинности для выхода из системы заключается в завершении сеанса.