Session Variable entspricht in OWIN-Selbst-Host

Question

Ich habe eine Beispiel-Web-API in einem OWIN-Prozess gehostet (selbst gehostet, nicht in IIS). Ich erhalte ein JWT-Token in meinem Controller, und ich möchte es in einem anderen Teil der Anwendung abrufen können, einer Klasse, die NserviceBus IMutateOutgoingTransportMessages implementiert. In meiner anderen Webanwendung POC (gehostet in IIS) habe ich eine einfache Sitzungsvariable verwendet und es funktioniert gut. Aber ich würde gerne wissen, was wäre der beste Weg, dies in meiner neuen selbst gehosteten OWIN-Umgebung zu tun? Statische Eigenschaft in der statischen Klasse?

Answer 1

Diese Frage ist sehr ausführlich und schwer zu beantworten ohne genaue Kenntnis Ihrer spezifischen Bedürfnisse. Hier ist meine Interpretation Ihrer Frage:

• Sie sind bereits jede Anfrage Unterzeichnung, vielleicht das Token im Browser session (oder sogar local) speichern, aber dies nicht ausreicht
• Sie müssen die Token außerhalb abrufen oder nicht in Bezug auf einen Anforderungszyklus (wenn nicht, ist es wahrscheinlich, wo Sie nach Antworten suchen werden sollen)
• Ihre Anwendung muss nicht sein staatenlos

Nur eine statische Eigenschaft für ein Token in einem Die statische Klasse würde natürlich als s beginnen oon wenn mehr als eine Anfrage die Anwendung gleichzeitig trifft. Das Implementieren einer Klasse, die eine Liste von Token verwaltet, kann eine Lösung sein, obwohl ich nicht sagen kann, welchen Schlüssel Sie verwenden sollten, um jedes Token zu identifizieren. Die Schnittstellendetails variieren je nachdem, ob Sie das Token mehr als einmal abrufen müssen.

Thread-Sicherheitsprobleme würden für alle Handhabung und Implementierung einer solchen Klasse gelten. Die Verwendung von Immutable Collections und funktionalen Programmierpraktiken als Inspiration kann helfen.

Wenn veraltete Tokens ein Problem darstellen (und sie wahrscheinlich aus Sicherheitsgründen, wenn nicht anders), müssen Sie herausfinden, wie Token nicht ihre Bereitschaft aushalten können, selbst wenn der Zyklus aus irgendeinem Grund ist nicht vollständig.

Wenn Sie sehen, wie Sie Session als Lösung in Ihrem POC verwendet haben, gehe ich davon aus, dass Sie ein ähnliches Verhalten wünschen und dass ein Benutzer nicht zwei Token gleichzeitig tragen darf. Sie könnten die Token in einer Datenbank oder sogar im lokalen Dateisystem speichern, wodurch Wartung und Gültigkeit zusammen ein separates Problem darstellen.

Es gibt Implementierungen von Cache-ähnlichen Funktionen, die bereits für selbst gehostete Anwendungen von OWIN verfügbar sind, und vielleicht würde eine davon als Abkürzung dienen, um alles selbst zu implementieren.

Wenn dieses Token-Geschäft tatsächlich der einzige Grund für die Einführung von Status in Ihrer Anwendung ist, dann wäre die beste Lösung IMHO, Ihre Architektur zu überdenken, damit die Anwendung staatenlos bleiben kann.

Answer 2

Ich stehe auf einem Server, den ich gerade für einen Kunden entwickle, vor einem ähnlichen Dilemma. Mein Problem ist, dass der Server mit einer veralteten Multithread-DLL (auch bekannt als SDK) Anrufe tätigen (und eine Live-Verbindung beibehalten) muss.

Ich hatte Mühe, dies mit einem regulären Web-API-Projekt auf IIS arbeiten zu lassen. Fehlgeschlagen, da IIS Threads recycelt, wenn festgestellt wird, dass ein Thread unberechtigt ist ... Wie sieht der SDK-Thread in dieser Perspektive aus? Außerdem muss das SDK in der Lage sein, den Anrufer (Client - Einzelseiten-App) zurückzurufen, und dazu benutze ich SignalR.

Ich versuchte dann ein mehrteiliges System (einzelne Seite + Web-API auf IIS + WCF-Dienst für die SDK-Integration).Es ist jedoch ein wahrer Albtraum, die Async-Kommunikation zu verwalten, die zwischen allen Apps stattfinden muss. Wiederum: Versagen.

Also ich zurück zu einem einzigen selbst gehosteten OWIN + WebAPI-Dienst in einer Konsolen-App (für jetzt). Mein Problem ist, dass einige der Aufrufe langwierig sind und in einem Worker-Thread verarbeitet werden. Ich habe es geschafft, die SignalR-Client-ID in jedem Ajax-Aufruf über Header zu übergeben. Ich kann die ID extrahieren, wenn ich im Web-API-Controller bin. Wenn die Task jedoch asynchron ausgeführt wird, muss die ID (über einen injizierten Dienst von Unity) von der Klasse abgerufen werden, die die asynchrone Task verwaltet. Hier ist mein Problem ähnlich wie bei Ihnen. In von IIS gehosteten Anwendungen haben wir HttpContext. Es wird bei jedem Client Aufrufe kontextualisiert, und folgt allen Thread-Änderungen in der Pipeline ... Aber nicht in selbst gehosteten OWIN WCF-Anwendungen ...

Ich bin in Thread Local Storage, CallContext ... und andere Mittel suchen die ursprünglichen Anruferinformationen während des Lebenszyklus des Async-Anrufs zu verfolgen. Ich habe über die OWIN-Pipeline gelesen, ich kann die Informationen in einer OWIN-Middleware erfassen ... aber wie kann ich diese Informationen sicher in injizierten Diensten speichern? Ich bin immer noch auf der Suche nach einer Antwort ...

Ich frage mich, ob Sie eine Lösung für dieses recht interessante Problem gefunden haben?

Ich bevorzuge das Hinzufügen zu Ihrem Thread, anstatt eine weitere parallele Thread/SO Frage zu starten.