Практические примеры использования промежуточного программного обеспечения OWIN

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

Что я могу использовать для промежуточного программного обеспечения OWIN, которое я уже не мог использовать обработчиков сообщений или модулей HTTP? Или они оба то же самое за исключением того, что последние два тесно связаны с IIS?
В большой части документации говорится, что OWIN позволяет развязывать веб-сервер и веб-приложение, т.е. удаление зависимости от IIS для хостинга используются приложения Web API. Но мне еще предстоит увидеть пример какого-либо веб-приложения или веб-api, который использовал OWIN, и был успешно перенесен с размещения на IIS, а затем на другую веб-страницу сервер. Итак, IIS и самостоятельный хостинг - единственный способ пойти на это развязка между веб-сервером и веб-приложением?
Когда я искал примеры промежуточного программного обеспечения OWIN, я получил только Katana и Helios, которые являются единственными реализациями спецификации OWIN. Катана почти закончена и не выходит за рамки пересмотра3, а Helios еще не поддерживается Microsoft в соответствии с некоторыми статьями. Итак, каково будущее OWIN в в этом случае?
Единственное подробное практическое использование, которое я видел до сих пор, - это используя OWIN для аутентификации с использованием OAuth 2. Любые другие подобные использования сохранения реализации OWIN в середине?
В моем способе настройки класса запуска я попытался объединить простые фрагменты кода промежуточного кода, как показано ниже, и чтобы увидеть запрос отправляется в: -

но получили ошибки:

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

Каковы различные виды промежуточного продукта, которые вы подключили в ваших проектах между веб-сервером и приложением?

Спасибо, что ответили на все или все выше.

Ответ 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.