Apprezzo tutto l'aiuto e il feedback. Le parti in grassetto sono parti critiche se questo è troppo dettagliato. Forse aiuterà a menzionare che sono uno sviluppatore verde. Ho trovato alcune informazioni utili dalle domande correlate pubblicate qui e su Stack Overflow ma nulla che si sentisse al 100%.
Sfondo
Attualmente al lavoro stiamo sviluppando un'applicazione web con rigidi vincoli stabiliti dal cliente. Normalmente siamo un negozio di Rails, ma il cliente voleva davvero lavorare con noi. Quindi, per adattarsi alla loro architettura, utilizzeremo ASP.NET. Non abbiamo molta esperienza con ASP.NET ma alcuni membri del team, incluso me stesso, hanno utilizzato .NET per applicazioni desktop.
Questa applicazione ha tre livelli e include:
- Server (s) di fronte pubblico
- Server (s) dei servizi Web
- Server di dati
Il cliente si aspetta una domanda elevata e potrebbero avere più server in uno qualsiasi dei livelli. C'è un firewall tra ogni livello. Da quanto ho capito, questo è un set molto comune.
Un obiettivo principale è ridurre al minimo i viaggi sul filo dal server pubblico al database.
Il problema
Come gestiamo l'autenticazione dell'utente senza ostacolare le prestazioni su un'applicazione N-Tier con potenzialmente molti server su ogni livello?
Cosa abbiamo fatto finora
Ci siamo divertiti con l'idea di utilizzare lo stato di visualizzazione, ma alla fine ho pensato che sarebbe stata una cattiva idea. Ovviamente non siamo contrari a rivedere lo stato di visualizzazione, ma riteniamo che lo stato di visualizzazione non offra alcun vantaggio rispetto ai cookie e rende semplicemente più difficile per un utente avere più schede della nostra applicazione aperte.
Ho esplorato il percorso dell'utilizzo dello stato di sessione predefinito con un archivio di sessioni implementato in modo personalizzato. Lo stato di sessione predefinito tende a generare più richieste andando oltre il filo. Effettuare il log in e out è ok, ma quando l'utente sta utilizzando l'app non lo vogliamo. Lo store di sessione personalizzato aiuta a minimizzare l'impatto, ma non abbastanza.
Conclusione e amp; Idea possibile
Dal momento che i viaggi nel database saranno inevitabili su quasi tutte le richieste una volta all'interno dell'applicazione, forse fornire all'utente una chiave per accedere con successo è il modo migliore per andare. Quindi, quando l'utente richiede una nuova pagina o pubblica una nuova pagina, potremmo inviare quella chiave con la relativa transazione SQL per la richiesta e convalidare la chiave. Credo che questo semplificherà immensamente il codice base.
Quindi, per ripetere il problema: Come gestiamo l'autenticazione dell'utente senza ostacolare le prestazioni su un'applicazione N-Tier con potenzialmente molti server su ogni livello? L'idea sopra sembra una solida implementazione ?
Grazie,
Jonathon