Ответ 1
Что я могу использовать для промежуточного программного обеспечения OWIN, которое я уже не мог использовать с помощью обработчиков сообщений или модулей HTTP? Или они оба одинаковы, за исключением того, что последние два тесно связаны с IIS?
Развязка с IIS является ее частью. Связующее ПО OWIN - это конвейер, который позволяет некоторым вещам, которые "сообщают OWIN", участвовать в запросе, если они выберут. IHttpHandler обрабатывает одну вещь - они не связаны цепью. Мне нравится больше сравнивать трубопровод с Global.asax. Я видел много заполненных обработчиков Global.asax, которые выполняют всевозможные действия, такие как аутентификация, авторизация, выталкивание HTTP-заголовков, таких как политики P3P, X-Frame-Options и т.д. Часть проблемы заключается в разработке повторно используемых компонентов из этого было трудно и зависело от ИИС. OWIN пытается удалить эти проблемы.
В большой части документации говорится, что OWIN позволяет развязать между веб-сервером и веб-приложением, т.е. удаление зависимостей от IIS для размещения приложений веб-API. Но я еще не видел пример какого-либо веб-приложения или веб-api, который использовал OWIN, и был успешно перенесен из размещения на IIS, а затем на другой веб-сервер. Итак, IIS и самостоятельный хостинг - единственный способ пойти на это развязку между веб-сервером и веб-приложением?
Это верно для WebAPI 2 и SignalR 2. На данный момент MVC 5 и старше не могут быть отделены от IIS. MVC 6 решит эту проблему и довольно большой капитальный ремонт. На веб-сайте ASP.NET есть учебник или два на собственном хостинге SignalR в приложении консоли. В учебнике вы увидите класс Startup
, как если бы он работал на IIS или IIS Express. Единственное, что делает консольное приложение по-разному, это перезагрузка сервера с помощью HttpListener в методе Main
.
[комментарий] Что касается пункта № 2 выше, каковы здесь компоненты owin? Является ли Katana компонентом owin или это код, который мы пишем, используя Katana или оба вместе?
OWIN действительно не намного больше уровня абстракции, действительно спецификации, между веб-приложением и веб-сервером. Существуют разные "реализации" OWIN в зависимости от сервера, на котором вы хотите работать. Katana - это реализация OWIN, которая запускает WebAPI 2 и SignalR 2. Kestrel - еще один пример реализации OWIN.
Когда я искал примеры промежуточного программного обеспечения OWIN, я получил только Katana и Helios, которые являются единственными реализациями спецификации OWIN. Katana почти закончена и не выходит за рамки версии3, и Helios пока не поддерживается Microsoft в соответствии с некоторыми статьями. Итак, каково будущее OWIN в этом случае?
Это все еще немного вверх-в-воздухе, но OWIN используется для разработки веб-сервера Kestrel, который позволяет ASP.NET 5 Core работать в Linux/OS X.
Единственное подробное практическое использование, которое я видел до сих пор, - это использование OWIN для аутентификации с использованием OAuth 2. Любые другие способы использования реализации OWIN в середине?
SignalR и WebAPI также используют OWIN. Это полезно, так что вы можете запустить концентратор SignalR как службу Windows, так же, как и для веб-API.
Любые другие применения для реализации OWIN в середине?
Независимость платформы. Наличие OWIN в середине означает, что я могу буквально выполнить xcopy мое веб-приложение MVC 6 Core от запуска IIS к Kestrel на моем Mac, а реализация OWIN позаботится об остальном.
В моем способе настройки класса запуска я попытался связать простые фрагменты кода промежуточного кода, как показано ниже, и чтобы можно было видеть отправленный запрос.
context.Request
не имеет индексатора в OWIN. Вместо этого используйте Get<>
:
app.Use(async (context, next) =>
{
context.Response.Write("hello world 2: " + context.Request.Get<object>("owin.RequestBody"));
await next();
});
Обратите внимание, что owin.RequestBody
- это немного детализация реализации, фактический тип возврата является внутренним. Я не уверен, что вы пытаетесь получить, если хотите строку запроса, используйте Query
из запроса или Headers
, если вы хотите заголовок HTTP.
Каковы различные виды промежуточного продукта, которые вы подключили к вашим проектам между веб-сервером и приложением?
Вещи для обеспечения безопасности, такие как компонент промежуточного программного обеспечения, который обрабатывал nonces в политике безопасности контента, о которой я писал в своем личном блоге здесь. Суть его заключалась в том, что я мог добавить HTTP-заголовок с помощью nonce:
public void Configuration(IAppBuilder app)
{
app.Use((context, next) =>
{
var rng = new RNGCryptoServiceProvider();
var nonceBytes = new byte[16];
rng.GetBytes(nonceBytes);
var nonce = Convert.ToBase64String(nonceBytes);
context.Set("ScriptNonce", nonce);
context.Response.Headers.Add("Content-Security-Policy",
new[] {string.Format("script-src 'self' 'nonce-{0}'", nonce)});
return next();
});
//Other configuration...
}
Оттуда, в представлениях Razor я мог бы добавить элементы nonce to <script>
, чтобы получить маркер из контекста owin.
Есть много других вещей, для которых он может быть использован. Другие рамки могут легко внедряться в процесс запроса/ответа. Рамка NancyFx теперь может использовать OWIN.