Come gestire una chiamata riposante in uno stato RESTless?

2

Ho un po 'di dilemma. Stiamo scegliendo il nostro DBContext utilizzando un generatore dinamico. Questo è fatto perché nella struttura attuale del database abbiamo un server separato per ogni "Cliente". Tutti questi database clienti utilizzano lo stesso modello in modo che siano tutti esattamente della stessa struttura.

Immettere la selezione del contesto da utilizzare con ciascuna chiamata. Stiamo usando WebApi 2 e angolare.

Quello che facciamo è nella prima "pagina" che scegli il tuo cliente e passiamo il customerId verso il basso e ho bisogno di memorizzare questo valore fino a quando l'utente non decide di scambiare. Detto questo, Session e WebApi2 non sono amici.

Ho un repository di base che necessita di customerId ogni volta che viene effettuata una chiamata a uno dei repository. Dobbiamo verificare che stiamo utilizzando il contesto giusto per quel cliente.

Quindi ... Ecco dove sono.

Devo infrangere le regole e usare Session per archiviare l'ID cliente? Potrei usare il mio contenitore DI per iniettare un'istanza di HttpContext.Current in ogni chiamata in modo da ignorare il fatto che la sessione è nullo su un WebApiController.

C'è un altro modo per gestirlo?

    
posta Robert 25.07.2014 - 21:12
fonte

1 risposta

4

Lo memorizzerei accanto all'autenticazione.

Se si utilizzano token OAuth 2.0, ad esempio, è possibile aggiungere un reclamo dove si imposta l'ID cliente. Se si utilizza l'autenticazione basata su cookie, impostare l'ID cliente all'interno di un cookie e risolverlo ogni richiesta.

In questo modo non si mantiene alcun stato sul server, ma si ha sempre l'ID cliente disponibile. Perché l'utente ti invia i dati in ogni richiesta.

Successivamente potresti scrivere un DelegatingHandler dove risolvi il CustomerId. Quindi è possibile aggiungerlo come rivendicazione all'utente corrente (ClaimsPrincipal) o qualsiasi altra cosa si adatti al proprio framework. Questo è anche un buon posto per rifiutare qualsiasi richiesta che non include un customerId.

Ma molto di ciò dipende dal modo in cui gestisci la tua logica di autenticazione.

    
risposta data 25.07.2014 - 22:11
fonte

Leggi altre domande sui tag