21 апреля 2026 года Microsoft выпустила внеплановое обновление .NET 10.0.7 и опубликовала security advisory CVE-2026-40372. Регрессия в пакете Microsoft.AspNetCore.DataProtection версий 10.0.0–10.0.6 позволяет атакующему без аутентификации подделать auth-cookie и залогиниться под админом приложения — а на Windows-деплоях это открывает путь и к SYSTEM-привилегиям на сервере.

Уязвимы версии 10.0.0–10.0.6 NuGet-пакета Microsoft.AspNetCore.DataProtection. Фикс — 10.0.7, вышел 21 апреля 2026 как out-of-band релиз.

Ошибка в HMAC-валидации: managed-энкриптор считает тег не по тем байтам payload и в ряде случаев отбрасывает уже вычисленный хеш.

Атакующий без аутентификации подделывает защищённые полезные данные: auth-cookie, antiforgery-токены, TempData, OIDC state.

Обновления пакета недостаточно. Токены, выпущенные за уязвимое окно, остаются валидными, пока вы не ротируете DataProtection key ring.

Microsoft нашла баг после жалоб пользователей на ошибки дешифровки в .NET 10.0.6 (Patch Tuesday 14 апреля).

Что такое ASP.NET Core Data Protection

Data Protection — встроенная в ASP.NET Core подсистема симметричной криптографии. Её задача — аутентифицированно шифровать небольшие полезные нагрузки, которые уходят к клиенту и возвращаются обратно.

Конкретно — это auth-cookie для логина пользователя, CSRF-токены (antiforgery — защита от межсайтовых запросов), промежуточный TempData (временные данные между двумя запросами одного пользователя), state-параметр в OIDC-флоу (OpenID Connect — протокол авторизации поверх OAuth 2.0), ссылки на сброс пароля и так далее. Всё это — «доверенные конверты», где сервер должен быть уверен, что клиент не подменил содержимое.

Работает по схеме encrypt-then-MAC: данные шифруются AES-256-CBC, а к шифру добавляется HMAC-SHA256-тег целостности, посчитанный по IV и шифртексту. При расшифровке сервер сначала проверяет HMAC — если тег не сходится, payload отбрасывается как подделанный. Именно в этой проверке и обнаружился баг.

В чём баг CVE-2026-40372

В версиях 10.0.0–10.0.6 managed-реализация authenticated encryptor в ряде случаев вычисляет HMAC-тег не по тем байтам payload — а затем отбрасывает уже посчитанный хеш. В результате атакующий может сконструировать payload, у которого валидный на вид тег совпадёт с содержимым подделки.

Microsoft описывает последствия в release notes 10.0.7 коротко: поломанная валидация позволяет «подделывать payloads, проходящие проверки подлинности DataProtection, и расшифровывать ранее защищённые данные». На практике это значит, что cookie аутентификации, antiforgery-токены, OIDC state и ссылки сброса пароля перестают быть доверенными контейнерами.

Почему это повышение привилегий: через подделанную auth-cookie атакующий логинится в приложение под привилегированным пользователем — обычно это аккаунт администратора. Дальше приложение само выдаёт ему уже легитимные токены: session-refresh, API-ключи, ссылки сброса пароля. На Windows-деплоях эти токены часто дают доступ к ресурсам, запущенным под NT AUTHORITY\SYSTEM — отсюда и SYSTEM-привилегии в заголовке advisory. CVSS-вектор уязвимости: AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N — сеть, низкая сложность, без привилегий и взаимодействия.

Кого конкретно задевает

• ASP.NET Core 10-приложения, у которых NuGet-копия Microsoft.AspNetCore.DataProtection версий 10.0.0–10.0.6 действительно загружается в рантайме — это и есть ключевое условие, проверьте lock-файл.
• Linux- и macOS-деплои — на них NuGet-копия пакета подтягивается чаще, чем на Windows: там реже полагаются на shared framework .NET-рантайма. Advisory Microsoft прямо указывает, что Windows-приложения без явной NuGet-зависимости не задеты.
• IdentityServer-решения вроде Duende, которые используют Data Protection для хранения OIDC-state и refresh-токенов.

«Shared framework» — это общий рантайм .NET, который ставится в систему отдельно от приложения (Microsoft.AspNetCore.App). «NuGet-копия» — это когда пакет Microsoft.AspNetCore.DataProtection указан в зависимостях проекта напрямую и загружается отдельно, переопределяя версию из shared framework. Разница критична: под уязвимость попадает именно NuGet-копия.

Почему одного обновления пакета мало

Тонкий момент из advisory, который легко пропустить: если атакующий успел выдать себе легитимные токены во время уязвимого окна (с 14 по 21 апреля для тех, кто накатил 10.0.6 на апрельский Patch Tuesday), эти токены продолжают работать и на 10.0.7. Подписи настоящие, DataProtection key ring тот же.

Поэтому фикс — это не только обновление NuGet-пакета, но и принудительная ротация DataProtection key ring. Без ротации вы закрываете будущие атаки, но старые уже выпущенные токены продолжат давать доступ.

Что делать с CVE-2026-40372 прямо сейчас

1. Обновите версию пакета в csproj или Directory.Packages.props до 10.0.7 — команда в блоке ниже.
2. Запустите restore и проверьте уязвимые зависимости. Флаг --include-transitive обязателен: без него вы не увидите пакет, который тянется транзитивно через Identity, Authentication.Cookies и прочие.
3. Пересоберите и передеплойте приложение — без dotnet build/publish и повторного деплоя фикс в рантайм не попадёт.
4. Ротируйте DataProtection key ring. Программно — вызов IKeyManager.CreateNewKey и затем RevokeAllKeys с текущим временем. Для Redis/Azure Blob Storage — форс-ротация через управляющий интерфейс провайдера. Учтите: ротация инвалидирует активные сессии пользователей, так что готовьте сотрудников к повторному входу.
5. Просмотрите логи аутентификации за период с 14 по 21 апреля. Куда смотреть: Azure AD sign-in logs, ELK/Serilog-индексы с cookie-auth событиями, IIS-логи со 200-ответами на /admin-эндпоинтах. Аномалии: логины без прохождения MFA, неожиданные session-refresh, массовые password-reset-запросы.
6. Инвалидируйте долгоживущие секреты, выданные в окне: API-ключи, personal access tokens, refresh-токены, integration-webhooks. Если есть подозрение на компрометацию — вращайте DB-пароли и service-account-credentials.

Не можете обновиться прямо сейчас? Временные меры: включите MFA на всех административных аккаунтах (это не закрывает подделку cookie, но добавляет барьер при использовании выписанных токенов), сократите срок жизни auth-cookie до минимума через ExpireTimeSpan в настройках CookieAuthenticationOptions, и форсируйте повторный вход всем пользователям через принудительный logout. Это митигация, не фикс — обновиться всё равно придётся.

Если приложение использует shared framework .NET и не тянет пакет из NuGet напрямую, уязвимость на него не распространяется. Проверяется двумя командами — dotnet --info покажет версию Microsoft.AspNetCore.App, а вторая команда подтвердит, тащит ли проект NuGet-копию:

В каком ряду это находится

Для ASP.NET Core это вторая серьёзная уязвимость за полгода. В октябре 2025 года Microsoft патчила CVE-2025-55315 — HTTP request smuggling в веб-сервере Kestrel с рейтингом «highest ever severity» для ASP.NET. Текущий CVE-2026-40372 бьёт в другое звено — в криптографию на уровне приложения, не веб-сервера — и открывает путь к эскалации привилегий без авторизации.

Формально Microsoft классифицирует severity как «Important», несмотря на CVSS 9,1 — внутренняя MSRC-шкала учитывает эксплуатируемость и требования к окружению, а не только CVSS-вектор. BleepingComputer и The Hacker News используют слово «critical», ориентируясь на CVSS. Публичного PoC-эксплойта пока нет, но out-of-band релиз 10.0.7 сам по себе сигнализирует, что эксплуатация считается реалистичной.

Если ваше приложение использует ASP.NET Core Data Protection, обновите пакет Microsoft.AspNetCore.DataProtection до 10.0.7 как можно скорее — это закроет и регрессию дешифровки, и саму уязвимость.

Если вы ведёте ASP.NET Core 10-приложение — сегодня же обновитесь до 10.0.7, передеплойтесь и ротируйте DataProtection key ring. Порядок действий — в разделе «Что делать» выше. Тянуть нельзя: атака одноходовая, а окно уже открылось.

Источники: BleepingComputer, dotnet/announcements, The Hacker News, .NET Blog, release notes 10.0.7.

Последнее октябрьское обновление системы — KB5066835 — нарушило работу localhost, что фактически лишило разработчиков возможности тестировать веб-приложения локально.

Проблему активно обсуждают на Microsoft Support Forums, Stack Overflow и Server Fault: серверы перестали отвечать на запросы, отвалилась отладка в Visual Studio, а ASP.NET-приложения не компилируются.

По оценкам экспертов, сбой затронул миллионы веб-разработчиков и инженеров, использующих Windows 11 в качестве локальных серверов и рабочих станций.

Что пошло не так

Пакет KB5066835 был задуман как обновление безопасности, улучшавшее сентябрьский релиз KB5065789, но именно он привел к поломке HTTP.sys — системного компонента ядра Windows, отвечающего за маршрутизацию локального HTTP-трафика.

После установки апдейта, localhost перестал отвечать на запросы, а соединения по HTTP/2 начали обрываться.

Как временно исправить

Microsoft пока официально не подтвердила проблему, но сообщество уже нашло обходное решение:

1. Удалить октябрьское обновление KB5066835.
2. Если не помогло — удалить и предыдущее KB5065789.
3. После этого localhost начинает работать штатно. Однако это временная мера и пользователи рискуют остаться без последних исправлений безопасности.

Неудачи Microsoft продолжаются

Это уже второй крупный сбой за неделю. В понедельник компания случайно «сломала» Media Creation Tool — утилиту для установки Windows — всего за день до окончания поддержки Windows 10.

А на прошлой неделе Microsoft окончательно обязала пользователей входить в Windows 11 только через онлайн-аккаунт, что вызвало волну критики.

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

C# 14: удобнее, быстрее, гибче

В новой версии языка появились важные улучшения:

• Поддержка System.Span<T> и System.ReadOnlySpan<T> на уровне языка, что делает работу с этими типами более естественной и повышает производительность без потери безопасности.
• Упрощенная работа с дженериками — теперь аргумент nameof может быть непривязанным (unbound) дженериком.
• Лямбда-выражения стали гибче: можно добавлять модификаторы параметров (scoped, ref, in, out, ref readonly) без указания их типов.

Эти нововведения позволяют писать более эффективный и компактный код без потери производительности.

Улучшенный JIT и производительность .NET 10

Разработчики продолжают снижать абстрактные накладные расходы популярных языковых конструкций:

• JIT-компилятор теперь умеет де-виртуализировать вызовы методов для интерфейсов массивов, что ускоряет работу с массивами.
• Автоматическое выделение небольших массивов в стеке, если они не содержат указателей на управляемую память (GC), снижает нагрузку на сборщик мусора.

Благодаря этим улучшениям .NET 10 стал еще быстрее, а нагрузка на память уменьшилась.

Новые API и улучшения в библиотеках

В стандартные библиотеки добавлены новые API, которые оптимизируют работу с текстовыми данными и 3D-графикой:

• Обработка символов теперь работает с Span<char>, что позволяет избежать лишних выделений памяти.
• Поддержка матриц левой трансформации, полезная при работе с 3D-графикой.
• Улучшена производительность ZipArchive для работы с архивами.

Эти обновления направлены на ускорение работы кода и снижение потребления памяти.

Обновления ASP.NET Core, Blazor и MAUI

• ASP.NET Core теперь поддерживает OpenAPI 3.1 и генерацию API-документации в формате YAML.
• Blazor получил подсветку синтаксиса маршрутов, что упрощает разработку.
• .NET MAUI теперь поставляется в виде .NET workload и через NuGet-пакеты, что облегчает фиксацию версий и тестирование экспериментальных сборок.

Также в Entity Framework появился метод LeftJoin для LINQ, что упрощает написание SQL-запросов.

Скачать и опробовать .NET 10 можно перейдя по ссылке на официальный сайт Microsoft.

Что такое CORS?

Браузеры строго следят за безопасностью и запрещают кросс-доменные запросы, если они не разрешены сервером. Это называется политикой одного источника (Same-Origin Policy). Она защищает пользователей от кражи данных, но иногда мешает законным сценариям.

Например, ваше веб-приложение загружено с siteA.com, но данные хранятся на api.siteB.com. По умолчанию браузер блокирует такие запросы. Как же обойти это ограничение? Использовать CORS (Cross-Origin Resource Sharing).

CORS — механизм, который позволяет серверу явно указывать, какие домены, схемы и порты могут запрашивать у него данные. Работает через специальные HTTP-заголовки.

Если браузер видит нестандартный запрос (например, PUT или DELETE), он сначала отправляет предварительный (preflight) запрос. Это проверка: серверу сообщают о запрашиваемом методе и заголовках, а тот решает — разрешить или запретить. Если сервер даёт добро, основной запрос выполняется.

CORS — не обходной путь, а стандарт, утверждённый W3C. Без него современные веб-приложения не могли бы безопасно взаимодействовать друг с другом.

Какие есть источники: same-origin – different-origin

Два адреса (URL) имеют одинаковый источник (same-origin), если они оба принадлежат одному домену.

Здесь у адресов один источник:

• https://test.com/index.html
• https://test.com/about.html

А здесь — разные:

• https://hello.net
• https://www.hello.com/foo.html

Так, если приложение обратится с адреса https://hello.net к странице https://www.hello.com/foo.html без настройки политики, то CORS запрос завершится ошибкой. Чтобы запрос обработался, мы должны сказать браузеру, что обращение к источнику https://www.hello.com разрешено.

Пример кросс-доменного запроса: JavaScript фронтенд-код, загруженный с URL https://domain-a.com, использует метод fetch() для запроса JSON-файла с URL https://domain-b.com/data.json.

CORS поддерживает безопасные кросс-доменные запросы — это снижает риски при использовании fetch() и XMLHttpRequest. Однако CORS лишь управляет разрешёнными междоменными запросами, но не гарантирует безопасность.

Включение CORS в ASP.Net Core приложении

Чтобы добавить механизм CORS в ASP.NET приложение, нужно:

1. Добавить сервисы CORS в контейнер сервисов приложения;
2. Включить промежуточное ПО CORS в конвейер обработки HTTP-запросов.

В первом шаге необходимо вызвать метод расширения AddCors для интерфейса IServiceCollection. Он добавляет в контейнер две сущности: ICorsService и ICorsPolicyProvider.

Существует также перегруженная версия этого метода расширения, позволяющая сконфигурировать политику CORS:

Во втором шаге вызывается метод расширения UseCors определенного для интерфейса IApplicationBuilder.

Этот метод добавляет промежуточное ПО CorsMiddleware в конвейер обработки HTTP-запросов. Для UseCors есть также перегруженная версия:

Есть три способа подключения CORS:

• В ПО промежуточного слоя с помощью именованной политики или политики по умолчанию.
• Использование маршрутизации конечных точек.
• С атрибутом [EnableCors].

[EnableCors] с именованной политикой обеспечивает лучший контроль в ограничении конечных точек, поддерживающих CORS.

CORS с именованной политикой и ПО промежуточного слоя

ПО промежуточного слоя CORS обрабатывает запросы между источниками. Следующий код применяет политику CORS ко всем эндпоинтам с указанными источниками:

Пример кода выше — часть Program.cs, показывающая инициализацию WebApplication. В ней объявляется константа политики CORS — MyAllowedOrigins. Далее вызывается AddCors, в который через параметры передается имя политики и набор адресов разрешенных источников. Ниже есть вызов метода расширения UseCors, в который передано то же самое имя политики CORS.

Важно:

• URL в настройках CORS не должны заканчиваться на '/', иначе заголовки не вернутся.
• При использовании ПО промежуточного слоя кэширования ответов (ResponseCaching) UseCors должен вызываться перед UseResponseCaching.
• При использовании Endpoints настройте CORS для выполнения между вызовами UseRouting и UseEndpoints.
• Обычно UseStaticFiles вызывается раньше UseCors, но если JavaScript загружает файлы, UseCors следует вызвать раньше.

CORS с политикой по умолчанию и ПО промежуточного слоя

Следующий выделенный код включает политику CORS по умолчанию:

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

Включение CORS с маршрутизацией конечных точек

Когда используется вызов UseEndpoints, можно подключить политику CORS к каждой отдельно взятой конечной точке, при этом можно указать имя применяемой политики в методе RequireCors:

В предыдущем коде:

• app.UseCors включает ПО промежуточного слоя CORS. Политики CORS привязываются к конечным точкам внутри метода UseEndpoints.
• Конечные /echo точки и точки контроллера разрешают запросы между источниками с помощью указанной политики – MyAllowSpecificOrigins, переданной в RequireCors.
• Конечные /echo2 точки и Razor страницы не разрешают запросы между источниками, так как политика по умолчанию не указана.

Включение CORS с помощью атрибутов

Атрибуты [EnableCors] позволяют подключить CORS только к конечным точкам, вместо глобальной настройки через промежуточное ПО. Плюс [EnableCors] без параметров включает политику CORS по умолчанию, а [EnableCors("{cors_policy_name}")] — именованную политику.

Атрибут [EnableCors] можно применить к:

• Странице Razor Page;
• Контроллеру целиком;
• Методам действия контроллера (Action-methods).

Если CORS включён одновременно через атрибут и промежуточное ПО, применяются обе политики.

Microsoft не рекомендует смешивать способы подключения CORS. Рекомендуется в одном приложении либо применять атрибуты [EnableCors], либо использовать ПО промежуточного слоя.

Вот пример, как применить специфическую политику к каждому экшн-методу контроллера:

Здесь показано, как создать две именованные политики CORS:

Чтобы обеспечить лучшее управление ограничением CORS-запросов, стоит:

• применять атрибуты [EnbleCors(“{policy_name}”)] с именованной политикой;
• не объявлять CORS-политику по умолчанию;
• не использовать маршрутизацию конечных точек.

Как запретить CORS

Запретить CORS для отдельных экшн-методов контроллера можно с помощью атрибута [DisableCors].

Примечание: атрибут [DisableCors] не запрещает CORS, которая была подключена при помощи методов расширения RequireCors в настройках маршрутизации конечных точек.

Пример, как запретить CORS для экшн-метода GetValues2:

Обратите внимание, что политика CORS разрешена для всего контроллера, так как контроллер декорирован атрибутом [EnableCors(“MyPolicy”)], а экшн-метод GetValues2 — [DisableCors], значит, CORS-политика не будет применена к этому методу.

Параметры политики CORS

Настройка разрешенных источников

Есть два метода расширения для указания разрешенных источников:

1. WithOrigins — позволяет указать список разрешенных источников;
2. AllowAnyOrigin — разрешает CORS-запросы к любым источникам.

Они влияют на заголовок Access-Control-Allow-Origin предварительных запросов.

Настройка разрешенных HTTP методов

Для указания разрешенных HTTP-методов есть похожая на предыдущие пара методов:

1. WithMethods — позволяет указать список разрешенных HTTP-методов;
2. AllowAnyMethod — разрешает использование любых HTTP-методов в CORS-запросах.

Они тоже влияют на заголовок Access-Control-Allow-Methods preflight-запросов.

Настройка разрешенных HTTP-заголовков

Для указания разрешённых HTTP-заголовков используются:

• WithHeaders — задаёт список разрешённых заголовков,
• AllowAnyHeader — разрешает любые заголовки.

AllowAnyHeader влияет на preflight-запросы и заголовок Access-Control-Request-Headers. Если заголовок не разрешён в WithHeaders, запрос будет отклонён. Если сервер вернёт 200 OK, но без CORS-заголовков, браузер заблокирует cross-origin запрос.

Настройка доступных заголовков ответов

По умолчанию браузер не предоставляет все заголовки ответов приложениям. По умолчанию предоставляются только:

• Cache-Control
• Content-Language
• Content-Type
• Expires
• Last-Modified
• Pragma

В спецификации CORS эти заголовки называются simple response headers. Чтобы сделать другие заголовки доступными для приложения, вызовите метод расширения WithExposedHeaders, передав массив имен заголовков в качестве параметра:

Передача учетных данных в запросах между источниками

В CORS-запросах учетные данные нужно специально обрабатывать. Речь идет о cookie и схемах аутентификации HTTP. Чтобы отправить учетные данные в CORS-запросе, клиент должен выставить свойство XMLHttpRequest.withCredentials в значение true.

Пример использования XMLHttpRequest напрямую в коде JavaScript:

Пример использования Fetch API:

Сервер должен разрешить передачу учетных данных. Чтобы это сделать, вызовите метод расширения AllowCredentials:

В результате появится заголовок Access-Control-Allow-Credentials в ответе сервера, значит, он разрешил передачу данных. Если в ответе не будет этого заголовка, то браузер не предоставит ответ, и CORS-запрос завершится ошибкой.

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

Спецификация CORS также говорит, что при использовании заголовков Access-Control-Allow-Credentials нельзя применять вызов AllowAnyOrigin при создании политики CORS.

Предварительные (preflight) запросы

Для некоторых CORS-запросов браузер отправляет preflight-запрос с HTTP-методом OPTIONS перед отправкой самого CORS. Браузер может не отправлять предварительный запрос в этих случаях:

• HTTP-метод основного CORS-запроса один из GET, HEAD или POST;
• Приложение не добавляет в запрос заголовки, кроме Accept, Accept-Language, Content-Language, Content-Type, Last-Event-ID;
• Запрос содержит заголовок Content-Type, то у него должно быть одно из значений: application/x-www-form-urlencoded, multipart/form-data, text/plain

Эти правила применяются к авторским заголовкам, которые задаются вызовом setRequestHeader объекта XMLHttpRequest. С User-Agent, Host, или Content-Length (заголовками браузера) так не работает.

У Preflight-запроса могут быть такие заголовки:

• Access-Control-Request-Method — HTTP-метод ( в основном CORS-запросе);
• Access-Control-Request-Headers — набор заголовков, которые будут установлены приложением в основном запросе.

Если предварительный запрос отклоняется сервером, то вылезет код 200 ОК, и браузер не будет пытаться отправлять CORS. При отладке в браузере (F12 tools) в консоли приложения появятся ошибки, если preflight-запрос отклонится сервером.

Чтобы разрешить передачу только определенных заголовков, вызывайте WithHeaders:

Чтобы разрешить передачу всех авторских заголовков, используйте вызов AllowAnyHeader.

Автоматическая обработка предварительных запросов

Если политика CORS применяется с помощью одного из приведенных ниже способов:

• глобально, с помощью вызова app.UseCors в модуле Program.cs;
• с помощью атрибута [EnableCors],

то ASP.NET будет автоматически обрабатывать запросы OPTIONS.

Обработка предварительных запросов с помощью атрибута [HttpOptions]

В ASP.NET предусмотрена возможность явного объявления методов для обработки предварительных запросов. Вот пример, как создать методы для обработки OPTIONS-запросов с [HttpOptions]:

Установка срока действия ответов для предварительных запросов

Браузер может закэшировать preflight-запросы, чтобы снизить нагрузку на сервер и сократить время обработки основных CORS-запросов. Чтобы ограничить срок хранения ответов в кэше, используйте заголовок Access-Control-Max-Age в ответе prefligh-запроса. Для этого при инициализации CORS-политики вызовите метод SetPreflightMaxAge:

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

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

Полезные ссылки

Cross-Origin Resource Sharing (CORS) - HTTP | MDN

Enable Cross-Origin Requests (CORS) in ASP.NET Core | Microsoft Learn

Больше про .NET — в нашем тг канале!

Почему важна конфигурация

Конфигурация в приложениях ASP.NET Core необходима для управления различными средами (разработка, продакшн и т.д.), выноса чувствительной информации, такой как строки подключения, и делает ваше приложение более гибким и поддерживаемым. ASP.NET Core поддерживает конфигурации из различных источников, таких как JSON-файлы (appsettings.json), переменные окружения и другие.

Настройка MongoDB

Начнем с определения подключения к MongoDB, а затем посмотрим, как оно интегрируется в систему конфигурации ASP.NET Core.

Шаг 1: Определение класса MongoSettings

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

Этот класс включает такие свойства, как ConnectionString, Database, RabbitMessagesCollectionName и MetricsCollectionName, все из которых отмечены как обязательные с помощью аннотаций данных.

Шаг 2: Добавление конфигурации в appsettings.json

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

Файл appsettings.json является основным источником конфигурации в ASP.NET Core. Вот пример того, как настройки MongoDB могут выглядеть в appsettings.json.

Здесь мы определяем раздел MongoConnection, который соответствует структуре нашего класса MongoSettings. Это позволяет фреймворку автоматически сопоставить структуру JSON с нашим классом.

Шаг 3: Настройка сервисов в Program.cs

Чтобы привязать конфигурацию из appsettings.json к нашему классу MongoSettings, мы используем методы Configure и AddOptions в Program.

С помощью services.Configure() фреймворк привязывает раздел MongoConnection из appsettings.json к классу MongoSettings. Это позволяет вам получить доступ к этим настройкам позже в приложении.

Шаг 4: Доступ к настройкам конфигурации

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

В приведенном примере мы внедряем IOptions в конструктор MyMongoService и получаем доступ к настройкам через свойство .Value. Паттерн IOptions гарантирует, что ваша конфигурация строго типизирована и проверена на старте.

Шаг 5: Валидация конфигурации

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

Здесь мы вызываем ValidateDataAnnotations для проверки аннотаций данных в классе MongoSettings (таких как [Required] и [Url]). ValidateOnStart гарантирует, что конфигурация проверяется при запуске приложения, предотвращая ошибки во время выполнения.

Заключение

Управление конфигурацией — это важный аспект приложений ASP.NET Core. Использование строго типизированных классов и паттерна Options обеспечивает чистый, поддерживаемый и гибкий способ работы с настройками, такими как подключения к базам данных. В этом примере мы продемонстрировали, как настроить и использовать MongoSettings в приложении ASP.NET Core, но этот же паттерн применим к любому разделу конфигурации.

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

Дополнительные материалы

Чтобы узнать побольше о конфигурации и паттерне Options в ASP.NET Core ознакомьтесь с официальной документацией:

• Конфигурация в ASP.NET Core
• Паттерн Options в ASP.NET Core

Для разработки будем использовать Visual Studio.

Создание ASP.NET проекта

Откройте Visual Studio Installer и нажмите «Изменить» на нужной среде разработки. Перед вами откроется список всех нагрузок. В категории Веб-разработка и облако нужно включить ASP.NET и разработка веб-приложений. После этого нажмите на кнопку Изменить в нижнем правом углу и дождитесь установки нагрузки.

Перейдите в Visual Studio и создайте новый проект, выбрав тип Веб-приложение ASP.NET (.NET Framework). Потом нужно выбрать необходимую модель приложения:

• Веб-формы — можно легко создавать динамические веб-сайты, используя сотни элементов управления и компонентов.
• MVC — эффективный, основанный на шаблонах способ создания динамических сайтов. Предоставляет полный контроль над разметкой для гибкой разработки.
• Веб-API — позволяет легко создавать HTTP службы для широкого диапазона клиентов. Идеальная платформа для сборки REST-приложений.
• Приложение SPA — одностраничное веб-приложение, которое загружает HTML-страницу и динамически обновляет её при взаимодействии с пользователем.

Выберете модель Веб-формы и завершите создание проекта.

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

В проекте сайта уже загружены некоторые библиотеки, необходимые для комфортного старта: CSS-фреймворк Bootstrap, JS-фреймворк jQuery, MSAjax и некоторые другие.

После создания тут уже присутствуют 3 страницы: Default, About и Contact. Каждая страница состоит из 3 файлов:

• Page.aspx — содержит в себе HTML-разметку конкретной страницы;
• Page.aspx.cs — отвечает за логику работы конкретной страницы;
• Page.aspx.designer.cs — является мостом между Page.aspx и Page.aspx.cs.

Вот так выглядит About.aspx:

Как видно, этот файл содержит лишь контент конкретной страницы. Вся общая разметка находится в Site.Master и Site.Mobile.Master.

Чтобы проверить и запустить проект, нажмите IIS Express или же традиционную клавишу F5. После этого все файлы скомпилируются и сайт откроется по адресу http://localhost:4400 в браузере по умолчанию. Номер порта может отличаться.

Создание веб-формы

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

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

Потом можно добавить ссылку на новую страницу в панель навигации в Site.Master:

Примечание Обратите внимание, что в ссылке указывается название страницы без расширения.

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

Во всех упоминаниях нужно заменить News на название вашей страницы. Теперь форма будет отображаться вместе с общей вёрсткой.

Для интеграции значений в вёрстку из aspx.cs используют специальный тег <%: %>:

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

Получение значений параметров из URL производится через статический класс Request, в котором хранятся и прочие данные о запросе:

Изучить все возможности веб-форм можно в официальной документации.

Движок представлений Razor

Razor позволяет делать вставки C# кода прямо в HTML разметке. Для этого нужно создать отдельный файл .cshtml (Контекстное меню проекта→Добавить→Страница представления MVC 5 (Razor)). Разметка в этом файле ничем не отличается от обычной HTML-вёрстки.

По умолчанию языком Razor является HTML. Для перехода с вёрстки на C# используют символ @, а сам блок кода помещается в фигурные скобки.

В Razor также можно выполнять неявные выражения прямо в HTML разметке:

Тут есть привычные для ЯП конструкции, которые могут значительно облегчить вёрстку. Вот некоторые из них:

Также всегда будет полезным просмотр open source проектов. Там вы найдёте не только лучшие практики по ASP.NET, но и просто решение популярных задач.

REST используется для создания легковесных, поддерживаемых и масштабируемых веб-сервисов. Сервис, построенный на REST архитектуре, называется RESTful-сервисом. REST использует HTTP — базовый сетевой протокол.

Далее в статье:

• Ключевые составляющие RESTful
• Методы RESTful
• Почему RESTful
• RESTful архитектура
• Принципы и ограничения RESTful
• Создаём свой первый RESTful веб-сервис с ASP.NET
• Запускаем наш веб-сервис
• Тестируем веб-сервис

Ключевые составляющие RESTful

Веб-сервисы прошли долгий путь с момента их появления. В 2002 году W3C выпустил определения WSDL и SOAP веб-сервисов. Это сформировало стандарт по созданию веб-сервисов.

В 2004 году W3C выпустил определение ещё одного стандарта под названием RESTful. В последние годы этот стандарт стал довольно популярным. На данный момент он используется многими известными сайтами по всему миру, в число которых входит и Twitter.

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

Ключевые составляющие реализации RESTful:

1. Ресурсы. Допустим, у нас есть сервер с записями о сотрудниках, а адрес веб-приложения — http://server.com. Чтобы получить доступ к записи сотрудника, мы можем выполнить команду http://server.com/employee/1, которая говорит серверу предоставить запись сотрудника под номером 1.
2. Методы запросов. Они говорят, что вы хотите сделать с ресурсом. Браузер использует метод GET, чтобы проинформировать удалённую сторону о том, что он хочет получить данные. Кроме GET есть много других методов вроде POST, PUT и DELETE. В примере с http://server.com/employee/1 выше браузер на самом деле использует метод GET, поскольку он хочет получить данные о сотруднике.
3. Заголовки запроса. Это дополнительные инструкции, посылаемые вместе с запросом. Они могут определять тип необходимого ресурса или подробности авторизации.
4. Тело запроса. Это данные, отправляемые вместе с запросом. Данные обычно отправляются, когда выполняется POST-запрос к REST веб-сервису. Зачастую в POST-запросе клиент говорит серверу, что он хочет добавить на него ресурс. Следовательно, тело запроса содержит подробную информацию о ресурсе, который необходимо добавить на сервер.
5. Тело ответа. Это основная часть ответа. В нашем примере на запрос http://server.com/employee/1 сервер мог бы прислать XML-документ с данными о сотруднике в теле ответа.
6. Коды ответа. Эти коды возвращаются сервером вместе с ответом. Например, код 200 обычно означает, что при отправке ответа не произошло никакой ошибки.

Методы RESTful

Представим, что у нас есть RESTful веб-сервис по адресу http://server.com/employee/. Когда клиент делает запрос к нему, он может указать любой из обычных HTTP-методов вроде GET, POST, DELETE и PUT. Ниже указано, что могло бы произойти при использовании соответствующего метода:

• POST — с его помощью можно создать новую запись сотрудника;
• GET — с его помощью можно запросить список сотрудников;
• PUT — с его помощью можно обновить данные сотрудников;
• DELETE — с его помощью можно удалять записи сотрудников.

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

• POST — этот метод нельзя применить, так как сотрудник с номером 1 уже существует;
• GET — этот метод можно использовать для получения данных о сотруднике под номером 1;
• PUT — этот метод можно использовать для обновления данных сотрудника под номером 1;
• DELETE — этот метод можно использовать для удаления записи сотрудника под номером 1.

Почему RESTful

В основном популярность RESTful обусловлена следующими причинами:

1. Разнородные языки и среды — это одна из основных причин:

• У веб-приложений, написанных на разных языках, есть возможность взаимодействовать друг с другом;
• Благодаря RESTful эти приложения могут находиться в разных средах, будь то Windows или Linux.

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

Twitter и Google дают доступ к их функциональности посредством RESTful веб-сервисов. Это даёт возможность любому клиентскому приложению взаимодействовать с этими сервисами с помощью REST.

2. Технологический бум – сегодня всё должно работать на разнообразных устройствах, будь то смартфон, ноутбук или кофеварка. Представляете, каких бы усилий стоило наладить взаимодействие этих устройств с помощью обычных веб-приложений? RESTful API делают эту задачу гораздо проще, поскольку, как было упомянуто выше, вам не нужно знать, что у устройства «под капотом».

3. Появление облачных сервисов — всё переезжает в облако. Приложения медленно перемещаются в облачные системы вроде Azure или Amazon, которые предоставляют большое количество API на основе RESTful архитектуры. Следовательно, приложения должны разрабатываться таким образом, чтобы они были совместимы с облаком. Так как все облачные архитектуры работают на основе REST, логично разрабатывать веб-сервисы тоже на REST-архитектуре, чтобы извлечь максимум пользы из облачных сервисов.

RESTful архитектура

Приложение или архитектура считается RESTful, если ей присущи следующие характеристики:

1. Состояние и функциональность представлены в виде ресурсов — это значит, что каждый ресурс должен быть доступен через обычные HTTP-запросы GET, POST, PUT или DELETE. Так, если кто-то хочет получить файл на сервере, у них должна быть возможность отправить GET-запрос и получить файл. Если он хочет загрузить файл на сервер, то у него должна быть возможность использовать POST или PUT-запрос. Наконец, если он хочет удалить файл, должна быть возможность отправить запрос DELETE.
2. Архитектура клиент-сервер, отсутствие состояния (stateless) и поддержка кеширования:Клиент-сервер — обычная архитектура, где сервером может быть веб-сервер, на котором размещено приложение, а клиентом — обычный веб-браузер;Архитектура без сохранения состояния означает, что состояние приложения не сохраняется в REST. Например, если вы удалили ресурс с сервера командой DELETE, то даже при получении положительного кода ответа нет гарантий, что он действительно был удалён. Чтобы убедиться, что ресурс удалён, необходимо отправить GET-запрос. С его помощью можно запросить ресурсы, чтобы посмотреть, присутствует ли там удалённый.

Принципы и ограничения RESTful

Архитектура REST основывается на нескольких характеристиках, которые описаны ниже. Любой RESTful веб-сервис должен им соответствовать, чтобы называться таковым. Эти характеристики также известны как принципы проектирования, которым нужно следовать при работе с RESTful-сервисами.

RESTful клиент-сервер

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

Отсутствие состояния

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

Кеш

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

Многослойная система

Суть этой концепции заключается в том, что любой дополнительный слой вроде промежуточного (слой, в котором создаётся бизнес-логика; это может быть дополнительный сервис, с которым клиент взаимодействует до сервера) можно поместить между клиентом и сервером, на котором располагается RESTful веб-сервис. Однако этот слой должен быть внедрён прозрачно, чтобы он не нарушил взаимодействия клиента и сервера.

Единообразие интерфейса

Это фундаментальное требование дизайна RESTful-сервисов. RESTful работает на уровне HTTP и использует нижеприведённые методы для работы с ресурсами на сервере:

• POST — для создания ресурса;
• GET — для его получения;
• PUT — для его обновления;
• DELETE — для его удаления.

Создаём свой первый RESTful веб-сервис с ASP.NET

Веб-сервисы можно создавать на множестве языков. Многие IDE можно использовать для создания REST-сервисов.

Мы напишем REST-приложение на .NET, используя Visual Studio.

Наш сервис будет работать со следующим набором данных «туториалов»:

Мы реализуем следующие RESTful методы:

• GET Tutorial — при его вызове клиент получает все доступные TutorialName;
• GET Tutorial/TutorialId — при его вызове клиент получает TutorialName, соответствующее переданному TutorialId;
• POST Tutorial/TutorialName — при его вызове клиент отправляет запрос на добавление туториала с переданным TutorialName;
• DELETE Tutorial/TutorialId — при его вызове клиент отправляет запрос на удаление туториала с TutorialName, соответствующему переданному TutorialId.

Теперь создадим шаг за шагом наш веб-сервис.

Шаг первый

Нам нужно создать пустое ASP.NET веб-приложение. Для этого откройте Visual Studio и создайте новый проект:

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

Шаг второй

В открывшемся окне перейдите по вкладкам C# → Веб. Выберите опцию «Веб-приложение ASP.NET (.NET Framework)» и введите необходимые данные проекта вроде названия и каталога:

Если далее у вас появилось следующее окно, выбирайте вариант «Пустой»:

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

Шаг третий

Теперь нужно создать файл нашего RESTful веб-сервиса. Для этого сначала нажмите Ctrl+Shift+A, либо кликните правой кнопкой по файлу проекта Webservice.REST и выберите опции Добавить → Создать элемент…:

В открывшемся окне найдите опцию «Служба WCF (с поддержкой технологии AJAX)» и дайте ей имя TutorialSevice.svc:

Прим. перев. Если вы не можете найти эту опцию, то попробуйте открыть Visual Studio Installer и загрузить часть среды, ответственную за работу с ASP.NET:

После выбора опции «Служба WCF (с поддержкой технологии AJAX)» Visual Studio создаст код, который будет основой для реализации веб-сервиса. WCF (Windows Communication Foundation) — библиотека, необходимая для налаживания взаимодействия между приложениями с помощью разных протоколов вроде TCP, HTTP и HTTPS. AJAX позволяет асинхронно обновлять веб-страницы, обмениваясь небольшими объёмами информации с сервером.

Шаг четвёртый

Теперь нам нужно внести изменения в конфигурационный файл Web.config. Он содержит настройки, необходимые для правильной работы приложения. Наше изменение позволит приложению отправлять и принимать данные как RESTful веб-сервис.

Откройте конфигурационный файл:

В открывшемся файле найдите строку <enableWebScript /> и замените её на <webHttp />.

Шаг пятый

Пора приниматься за код. Откройте файл TutorialService.svc. Сначала добавим код для отображения наших данных. Создадим список со строками «Arrays», «Queues» и «Stacks». Они будут отражать имена доступных туториалов:

Шаг шестой

Теперь напишем код для нашего метода GET в том же файле. Этот метод будет запускаться при каждом вызове сервиса из браузера. Он будет использоваться для получения доступных туториалов:

Строка [WebGet(UriTemplate="/Tutorial")] — самая важная. Она нужна для определения того, как мы будем вызывать этот метод по URL. Если наш сервис расположен по адресу http://localhost:52645/TutorialService.svc и в его конец мы добавим «/Tutorial» и получим http://localhost:52645/TutorialService.svc/Tutorial, то будет вызван вышеприведённый код. Атрибут WebGet является параметром, который позволяет GetAllTutorials() быть RESTful-методом, который можно вызвать GET-запросом.

В самом методе GetAllTutorials() находится код, который собирает все названия туториалов и возвращает их в одной строке.

Шаг седьмой

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

Как и в предыдущем примере, первая строка — самая важная, так как определяет то, как мы будем вызывать этот метод. Если мы сделаем запрос http://localhost:52645/TutorialService.svc/Tutorial/1, то веб-сервис должен вернуть TutorialName, соответствующий TutorialId с индексом 1.

Метод GetTutorialByID() реализует описанную логику. Обратите внимание на то, что мы приводим TutorialId к типу Integer. Это связано с тем, что всё передаваемое в адресную строку браузера является строкой. А поскольку индексом списка не может быть строка, мы добавляем код, необходимый для преобразования в число.

Шаг восьмой

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

На первой строке находится атрибут WebInvoke, прикреплённый к нашему методу, что позволяет вызывать его с помощью POST-запроса. Для атрибутов RequestFormat и ResponseFormat мы указываем JSON, так как именно с этим форматом работает RESTful веб-сервис.

Шаг девятый

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

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

В самом методе DeleteTutorial() мы приводим переданный TutorialId к типу Integer и удаляем из списка соответствующий элемент.

В итоге код должен выглядеть так (не учитывая элементов, которые были там изначально):

Запускаем наш веб-сервис

Мы создали наш веб-сервис, пора его запустить.

Сначала кликните правой кнопкой по файлу проекта Webservice.REST и выберите опцию «Назначить автозагружаемым проектом», чтобы Visual Studio запустила этот проект при запуске всего решения:

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

После запуска должно открыться окно браузера. Перейдите по адресу http://localhost:51056/TutorialService.svc/Tutorial и в зависимости от выбранного браузера вы увидите что-то такое:

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

В этом примере браузер делает GET-запрос и тем самым вызывает написанный нами метод GetAllTutorials(), который возвращает список со всеми туториалами.

Тестируем веб-сервис

Выше мы увидели, как браузер делает GET-запрос для вызова GetAllTutorials(). Давайте проверим другие сценарии.

1. GET Tutorial/TutorialId — при вызове этого RESTful API клиент должен получить TutorialName, соответствующий переданному TutorialId.

Для вызова просто добавьте строку «/1» в конце URL, чтобы получить http://localhost:51056/TutorialService.svc/Tutorial/1. После перехода по этой ссылке вы должны увидеть следующее:

В этот раз был вызван метод GetTutorialByID(), который вернул туториал с индексом 1 — «Queues».

2. POST Tutorial/TutorialName — при вызове этого API клиент отправляет запрос на добавление переданного TutorialName, который сервер должен добавить в список. В этот раз нам понадобится инструмент Fiddler, который можно бесплатно скачать с официального сайта.

Запустите Fiddler и выполните следующие действия:

1. Переключитесь на вкладку Composer. Она используется для создания запросов, которые можно отравить любому веб-приложению;
2. Установите тип запроса равным «POST», а в URL вставьте адрес сервиса, в нашем случае это http://localhost:51056/TutorialService.svc/Tutorial;
3. В окне, где уже есть строка «User-Agent: Fiddler» добавьте строку «Content-Type: application/json». Наш сервис работает только с данными в формате JSON, помните?
4. Осталось ввести данные в поле «Request Body». Наш метод для POST-запросов принимает параметр str. Передавая строку {"str": "Trees"}, мы указываем, что хотим добавить в список значение «Trees».

Нажмите на кнопку «Execute». После этого нашему сервису будет отправлен запрос на добавление «Trees».

Чтобы убедиться, что всё прошло как надо, получим список всех туториалов, перейдя по ссылке http://localhost:51056/TutorialService.svc/Tutorial. Вы должны увидеть следующее:

3. DELETE Tutorial/TutorialId — при вызове этого API клиент отправит запрос на удаление из списка TutorialName, которое соответствует переданному TutorialId.

Запустите Fiddler и выполните следующие действия:

1. Переключитесь на вкладку Composer;
2. Установите тип запроса равным «DELETE», а в URL вставьте адрес сервиса вместе с id элемента, который хотите удалить. Если мы хотим удалить второй элемент, то адрес будет http://localhost:51056/TutorialService.svc/Tutorial/1.

Нажмите на кнопку «Execute», чтобы отправить DELETE-запрос на удаление элемента «Queues».

Если мы опять запросим список всех туториалов, мы увидим, что их стало меньше на один:

Подведём итоги

• REST используется для создания легковесных, поддерживаемых и масштабируемых веб-сервисов;
• Всё больше приложений переходят на RESTful архитектуру, что обусловлено большим количеством разнообразных устройств и перемещением многих приложений в облако;
• Основные составляющие REST — ресурсы, которые располагаются на сервере, и методы GET, POST, PUT и DELETE, которые можно использовать для работы с этими ресурсами;
• Для создания RESTful веб-сервисов можно использовать Visual Studio и .NET;
• При проверке работы сервиса с запросами вроде POST, DELETE и PUT нужно использовать сторонний инструмент Fiddler, который позволяет посылать серверу запросы таких типов.

Чтение по теме:Как защитить веб-приложение: основные советы, инструменты, полезные ссылки

Ключевые изменения .NET Core

Microsoft акцентировала внимание на решении проблем с безопасностью. Устранены некоторые уязвимости в ASP.NET Core. Исправлена ошибка при прерывании неверного запроса, позволявшая злоумышленнику реализовать атаку по отказу в обработке. Помимо этого, компания составила руководство для разработчиков, в продуктах которых присутствует эта уязвимость.

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

В ASP.NET Core исправлена ошибка в обработке сертификатов, позволявшая предъявлять по запросу данные с истекшим сроком.

Скачать обновление можно на сайте Microsoft.

Напомним, NET Core 2.1 вышла в конце мая 2018 года, и Microsoft регулярно дорабатывает эту платформу.

В курсе рассматриваются основные сведения и приемы работы с элементами управления, принципы и способы оформления страниц, возможности работы с базами данных. Дается представление о создании скриптов и реализации ajax-приложений, а также основные инструменты отладки веб-приложения в Visual Studio.

Смотрите еще больше обучающих материалов по ASP.NET.

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

В этой статье мы создадим тестового бота с использованием Microsoft Bot Framework, обучим и протестируем его с помощью встроенного эмулятора. Идея бота проста — он должен понимать человеческий язык и отвечать, когда его спросят о погоде в каком-то городе.

Архитектура проекта

Итак, вот как будет выглядеть схема работы нашего бота:

Как можно понять, после получения сообщения оно сначала отправляется в «умное» API Microsoft Cognitive Services — Language Understanding Intelligent Service, сокращенно «LUIS». Именно с использованием LUIS мы сможем обучить бота понимать естественный язык и отвечать прогнозом погоды. В ответ на каждое такое сообщение LUIS возвращает всю содержащуюся в нем информацию в JSON.

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

Используем LUIS

Видео, кратко объясняющее принцип работы LUIS, можно посмотреть здесь.

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

LUIS разбивает приложения на действия, на этом скриншоте их три: погода (weather), состояние (condition) и место (location). Подробнее о действиях (intents) рассказано в официальном видео выше.

LUIS в действии

Выполнив базовое обучение, попробуем сделать HTTP запрос к LUIS и получить ответ в JSON. Давайте спросим его: «Is it cloudy in Seattle?» («В Сиэтле сейчас облачно?») — и вот что он нам вернет:

Теперь попытаемся использовать это в реальном боте.

Создание бота

В качестве платформы будем использовать ASP.NET. Для начала необходимо добавить шаблон Bot Framework в Visual Studio. Подробную инструкцию по этому найдете в официальной документации.

Теперь создадим новый проект с его использованием:

По сути, это простое приложение всего с одним контроллером, который и занимается обработкой сообщений от пользователей. Давайте напишем простой код, который на любое сообщение будет отвечать «Welcome to Streamcode»:

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

Подробная инструкция по установке и настройке эмулятора.

Запустив эмулятор, попробуем пообщаться с новосозданным ботом:

Как и ожидалось, на все сообщения он отвечает одной фразой.

Интеграция с LUIS

Так как эта статья является вводом в Microsoft Bot Framework, то мы не будем публиковать тут все исходные коды, приведем лишь самые важные. Остальные мы разместили в GitHub-репозитории.

1. Передаем сообщение в LUIS, получаем ответ и на основе наиболее релевантного «действия» (intent) выдаем ответ.

Прогнозы погоды получаем через API OpenWeatherMap.com.

2. Заготовленные шаблоны ответов.

Финальный результат:

Материалы для дальнейшего обучения

1. Документация по Bot Framework
2. Channel9: создаем чат-бота
3. Документация по LUIS
4. Microsoft Cognitive Services

Как сообщает Скотт Хансельман, один из самых известных и уважаемых в мире специалистов по веб-технологиям Microsoft, назвать ASP.NET 5 именно так было неправильно. Понятно, что часто в выборе того, как назвать что-то новое принимает участие больше одного человека, и не всегда выбор так очевиден. К тому же, ASP.NET — это хороший бренд, известный вот уже 15 лет, а ASP.NET 4.6 — выпущенная и поддерживаемая версия продукта, которую можно скачать и использовать.

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

Итак, встречаем изменения:

• ASP.NET 5 теперь ASP.NET Core 1.0;
• .NET Core 5 становится .NET Core 1.0;
• Entity Framework 7 называем Entity Framework Core 1.0 или EF Core 1.0.

Почему 1.0? Потому что это нечто новое. Вся концепция  .NET Core стала новой.

Что же выбрать для своих проектов?

Чтобы быть до конца честными, скажем, что на текущий момент ASP.NET 4.6 является более взрослой и полноценной платформой. Она хорошо протестирована и доступна для боевого использования уже сейчас. А вот ASP.NET Core 1.0 — это только первый релиз, в котором ещё нет SignalR и Web Pages. В нём не поддерживается VB и F#. Всё это будет, но в будущих версиях.