Эквивалент переменной сеанса в собственном хосте OWIN

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

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

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

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

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

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

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

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

Я столкнулся с аналогичной дилеммой на сервере, который я сейчас разрабатываю для клиента. Моя проблема в том, что сервер должен совершать вызовы (и поддерживать живое соединение) с устаревшей многопоточной DLL (также известной как SDK).

Я изо всех сил пытался заставить это работать на IIS с обычным проектом веб-API. Серьезный сбой, поскольку IIS повторно использует потоки, когда определяет, что поток становится мошенническим... ведь именно так выглядит поток SDK с этой точки зрения. Кроме того, SDK должен иметь возможность обратного вызова вызывающей стороны (клиент — одностраничное приложение), и для этого я использую SignalR.

Затем я попробовал систему, состоящую из нескольких частей (одна страница + веб-API на IIS + служба WCF для интеграции SDK). Но это настоящий кошмар для управления из-за двусторонней асинхронной связи, которая должна происходить между всеми приложениями. Опять же: неудача.

Поэтому я вернулся к единой собственной службе OWIN + WebAPI в консольном приложении (на данный момент). Моя проблема в том, что некоторые вызовы длинные и обрабатываются в рабочем потоке. Мне удалось передать идентификатор клиента SignalR в каждом вызове ajax через заголовки. Я могу извлечь идентификатор в контроллере веб-API. Но когда задача становится асинхронной, мне нужно получить идентификатор (через службу, внедренную в Unity) из класса, который управляет асинхронной задачей. Здесь моя проблема похожа на вашу. В приложениях, размещенных на IIS, у нас есть HttpContext. Он контекстуализируется при каждом вызове клиента и следует за любыми изменениями потока в конвейере... Но не в самостоятельных приложениях OWIN WCF...

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

Мне интересно, нашли ли вы решение этой довольно интересной проблемы?

Я предпочитаю добавлять в вашу ветку, а не начинать еще одну параллельную ветку / ТАК вопрос.