Implementazione dell'autenticazione utente su un'applicazione Web N-Tier

4

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

    
posta Jon Mcdonald 16.09.2013 - 20:29
fonte

1 risposta

2

Forse sono cinico ma sento un problema comune qui. Si aspettano una strong domanda e quindi stanno distribuendo tutto fin dall'inizio con un'attenta ottimizzazione. Prima che abbiano un prodotto.

Come fanno a sapere che riceveranno tutto questo traffico?

Se ottengono tutto questo traffico, come fanno a sapere che qualcosa di semplice non scala?

La soluzione giusta è implementare una semplice funzione che dietro le quinte fa una semplice richiesta di database, ma che in seguito può essere sostituita con qualcosa di sofisticato. E poi non preoccuparti fino a quando non ci sarà un problema provato. Una decina di anni fa ho fatto qualcosa di simile e non abbiamo riscontrato problemi di ridimensionamento fino a 100k pagine dinamiche / ora. E quando abbiamo riscontrato problemi lì, non stava colpendo il login che era il problema!

Sì, potrei suggerire molte architetture fantasiose che scalano meglio. Ne ho costruiti anche io. Ma finché non hai bisogno di andare lì, supponi che non lo farai.

    
risposta data 17.09.2013 - 18:20
fonte

Leggi altre domande sui tag