WebApi su Database Differenti

[Valerio.Scordato]

Ho un' applicazione che, in base all'utente, modifica la default connection string di un database per poter consentire l'utilizzo di Db diversi ad Utenti diversi

Se creo una WebApi da un documento per caricare / verificare dati avrei bisogno di capire su che database caricare questi documenti, Considerato che il collegamento alla WebApi non prevede l'autenticazioneù

Avere idee?

[d.termini]

Puoi far passare negli header o come parametro lo userid e in base a quello connetterti al DB di sua competenza.

La gestione probabilmente la devi fare in fase di inizializzazione, intercettare la request e pilotare la connessione.

Se dalla parte del chiamante hai InDe e lo fai direttamente da documento non ricordo bene in che momento puoi personalizzare la chiamata ma si può sicuramente fare.

[eurekapv]

Ciao io di solito uso questo sistema per gestire i multi clienti su DB diversi per chiamate Web Api

a) Ho un database condiviso (dove dentro ci sono i clienti e le stringhe di connessione): i miei record hanno come chiave un DOCID quindi ogni cliente ha suo DOCID
b) Dall'esterno per ogni chiamata chiedo venga aggiunta 1 o piu chiavi nell'Header della chiamata (all'interno delle chiavi devo trovare il DOCID GUID del cliente)

Il metodo piu' rapido ma anche piu pericoloso è fare aggiungere un header tipo api-key = GUIDCLIENTE (Trasformo il docidi in guid cosi è piu leggibile)
Quando ricevo la chiamata controllo il parametro e a seconda mi posiziono sul db corretto

Il metodo meno rapido ma di piu difficile interpretazione => dall'esterno faccio creare un JSON WEB TOKEN (che contenga come payload il GUID del cliente)
Encodato come si deve lo aggiungo all'header della chiamata e poi faccio lo stesso giro per connettermi al db.

Si potrebbe anche pensare di fare una prechiamata con autorizzazione normale (user/password) che rilascia una chiave ' a scadenza' e che debba essere usata per le chiamate successive.

Il trucco è comunque farsi dire in qualche modo chi sta chiamando.

[Valerio.Scordato]

Ciao io di solito uso questo sistema per gestire i multi clienti su DB diversi per chiamate Web Api

a) Ho un database condiviso (dove dentro ci sono i clienti e le stringhe di connessione): i miei record hanno come chiave un DOCID quindi ogni cliente ha suo DOCID
b) Dall'esterno per ogni chiamata chiedo venga aggiunta 1 o piu chiavi nell'Header della chiamata (all'interno delle chiavi devo trovare il DOCID GUID del cliente)

Il metodo piu' rapido ma anche piu pericoloso è fare aggiungere un header tipo api-key = GUIDCLIENTE (Trasformo il docidi in guid cosi è piu leggibile)
Quando ricevo la chiamata controllo il parametro e a seconda mi posiziono sul db corretto

Il metodo meno rapido ma di piu difficile interpretazione => dall'esterno faccio creare un JSON WEB TOKEN (che contenga come payload il GUID del cliente)
Encodato come si deve lo aggiungo all'header della chiamata e poi faccio lo stesso giro per connettermi al db.

Si potrebbe anche pensare di fare una prechiamata con autorizzazione normale (user/password) che rilascia una chiave ' a scadenza' e che debba essere usata per le chiamate successive.

Il trucco è comunque farsi dire in qualche modo chi sta chiamando.

Grazie Pietro, lo fai nell'evento OnWebApi o è già troppo tardi?
E se lo faccio su Inizialize riesco a leggere gli Headers?

[Valerio.Scordato]

Puoi far passare negli header o come parametro lo userid e in base a quello connetterti al DB di sua competenza.

La gestione probabilmente la devi fare in fase di inizializzazione, intercettare la request e pilotare la connessione.

Se dalla parte del chiamante hai InDe e lo fai direttamente da documento non ricordo bene in che momento puoi personalizzare la chiamata ma si può sicuramente fare.

Grazie, stavo tentando di capire se farlo nell' evento Inizialize (a patto che abbia già a disposizione gli Headers) o nell'evento OnWebAPI (se non è troppo tardi)

[eurekapv]

Conosci il funzionamento del Document Helper ?
Io ho una classe che estende IDDocument Helper (chiamata Class HelperDoc)
Poi ho una variabile globale di tipo Class Helper Doc
Nell'evento Initialize associo la variabile alla proprietà dell'applicazione quindi

Code: Select all

nomeapp.documentHelper = VariabileDocHelper

Cosi' tutto è accentrato nella classe Helper Doc

Ora rendi globale l'evento onWebApi su un documento e ti finisce sulla tua Class Doc Helper

Tutte le chiamate passeranno da qui e qui decidi se farle passare oppure no controllando il famoso GUID ed impostando la connection string

[Valerio.Scordato]

Conosci il funzionamento del Document Helper ?
Io ho una classe che estende IDDocument Helper (chiamata Class HelperDoc)
Poi ho una variabile globale di tipo Class Helper Doc
Nell'evento Initialize associo la variabile alla proprietà dell'applicazione quindi

Code: Select all

nomeapp.documentHelper = VariabileDocHelper

Cosi' tutto è accentrato nella classe Helper Doc

Ora rendi globale l'evento onWebApi su un documento e ti finisce sulla tua Class Doc Helper

Tutte le chiamate passeranno da qui e qui decidi se farle passare oppure no controllando il famoso GUID ed impostando la connection string

Grazie mille, sei come sempre chiaro ed esaustivo

[eurekapv]

Grazie Valerio :-)

[d.termini]

Puoi far passare negli header o come parametro lo userid e in base a quello connetterti al DB di sua competenza.

La gestione probabilmente la devi fare in fase di inizializzazione, intercettare la request e pilotare la connessione.

Se dalla parte del chiamante hai InDe e lo fai direttamente da documento non ricordo bene in che momento puoi personalizzare la chiamata ma si può sicuramente fare.

Grazie, stavo tentando di capire se farlo nell' evento Inizialize (a patto che abbia già a disposizione gli Headers) o nell'evento OnWebAPI (se non è troppo tardi)

Su onWebApi se non ricordo male è già tardi perché ha già gestito la richiesta, infatti noi abbiamo dovuto implementare prima l'autenticazione su initialize.

[eurekapv]

OnWebApi è il punto corretto
La richiesta vera non è ancora stata elaborata (qualsiasi essa sia)

Infatti è presente un parametro output Cancel proprio per interrompere il metodo classico del framework e gestire la chiamata manualmente
Magari d.termini avevate qualche altra richiesta particolare che non siete stati in grado di gestire nella OnWebApi.

Anche sulla Guida WebApi a pagina 16 si possono trovare esempi in merito.