Equivalente della variabile di sessione nell'host automatico OWIN

Question

Ho un'API Web di esempio ospitata in un processo OWIN (self hosted, non in IIS). Ricevo un token JWT nel mio controller e voglio essere in grado di recuperarlo in un'altra parte dell'applicazione, una classe che implementa NserviceBus IMutateOutgoingTransportMessages. Nella mia altra applicazione web POC (ospitata in IIS), ho usato una semplice variabile di sessione e funziona perfettamente. Ma mi piacerebbe sapere quale sarebbe il modo migliore per farlo nel mio nuovo ambiente self hosted OWIN? Proprietà statica in classe statica?

Answer 1

Questa domanda è davvero ampia e difficile da rispondere senza una conoscenza dettagliata delle vostre esigenze specifiche. Ecco la mia interpretazione del problema:

• sei già firmare ogni richiesta, forse immagazzinare il token nel browser sessionStorage (o anche localStorage), ma questo non è sufficiente
• È necessario recuperare il token di fuori o non in relazione a qualsiasi ciclo di richiesta (se non, questo è probabilmente dove si dovrebbe essere alla ricerca di risposte)
• l'applicazione non ha bisogno di essere apolidi

solo una proprietà statica per un gettone in un la classe statica, naturalmente, inizierebbe a rompersi come in s oo come più di una richiesta colpisce l'applicazione allo stesso tempo. Implementare una classe che mantiene un elenco di token può essere una soluzione, anche se non posso dire quale chiave si dovrebbe usare per identificare ogni token. I dettagli dell'interfaccia variano a seconda di cose come se fosse necessario recuperare il token più di una volta.

Problemi di sicurezza del filo si applicherebbero a tutte le manipolazioni e l'implementazione di tale classe. Usare Immutable Collections e pratiche di programmazione funzionale come ispirazione può aiutare.

Se i token persistenti rappresentano un problema (e probabilmente lo farebbero da un punto di vista della sicurezza, se non altro), è necessario capire come assicurarsi che i token non si ostinino al loro benvenuto, anche se il ciclo è per qualche motivo non completato.

Vedere come hai usato Session come soluzione nel tuo POC, presumo che tu voglia un comportamento simile, e che a un utente non dovrebbe essere permesso di portare due token contemporaneamente. È possibile memorizzare i token in un database o anche nel file system locale, rendendo la manutenzione e la validità un problema separato tutti insieme.

Ci sono implementazioni di funzionalità simili a cache già disponibili per le applicazioni self-host OWIN e forse una di queste sarebbe una scorciatoia per implementare tutto da solo.

Se questo business di token, infatti, è l'unica ragione per introdurre lo stato nella propria applicazione, la migliore soluzione IMHO sarebbe quella di ripensare la propria architettura in modo che l'applicazione possa rimanere apolidi.

Answer 2

Sto affrontando un dilemma simile su un server che sto attualmente sviluppando per un cliente. Il mio problema è che il server deve effettuare chiamate (e mantenere una connessione attiva) con una DLL legacy, multithread, (ovvero l'SDK).

Ho faticato per farlo funzionare su IIS con un normale progetto API Web. Failed male dato che IIS ricicla i thread quando determina che un thread sta diventando rogue ... witch è come appare il thread SDK in quella prospettiva. Inoltre, l'SDK deve essere in grado di richiamare sul chiamante (client - app a singola pagina) e per questo sto utilizzando SignalR.

Ho quindi provato un sistema multiparte (singola pagina + web API su IIS + servizio WCF per l'integrazione SDK).Ma è un vero incubo da gestire a causa della comunicazione asincrona bidirezionale che deve avvenire tra tutte le app. Di nuovo: fallimento.

Così ho ripristinato un singolo servizio OWIN + WebAPI self-service in un'app console (per ora). Il mio problema è che alcune chiamate sono lunghe e vengono elaborate in un thread di lavoro. Sono riuscito a passare l'ID del client SignalR in ogni chiamata ajax tramite le intestazioni. Posso estrarre l'id quando nel controller web api. Ma quando l'attività diventa asincrona, ho bisogno di ottenere l'id (tramite un servizio Unity injected) dalla classe che gestisce l'attività asincrona. Qui è dove il mio problema è simile al tuo. Nelle app ospitate da IIS, abbiamo HttpContext. Viene contestualizzato su ogni chiamata del client e segue eventuali modifiche del thread nella pipeline ... Ma non nelle app OWIN WCF auto-ospitate ...

Sto cercando Thread Storage locale, CallContext ... e altri mezzi di tenere traccia delle informazioni sul chiamante originale durante il ciclo di vita della chiamata asincrona. Ho letto della pipeline OWIN, posso acquisire le informazioni in un middleware OWIN ... ma come conservare in modo sicuro tali informazioni per l'utilizzo nei servizi iniettati? Sto ancora cercando una risposta ...

Mi chiedevo se hai trovato una soluzione a questo problema piuttosto interessante?

Preferisco aggiungere alla discussione anziché avviare un'altra discussione parallela/domanda SO.