A causa di determinati requisiti / vincoli, mi chiedo se inviare login utente e password ad ogni richiesta.
Questo in qualche modo non mi sembra molto buono, anche se penso che per il mio caso particolare potrebbe avere un senso: ridurrebbe il numero di richieste HTTP, ridurrà la latenza e semplificherà il codice di frontend.
Ecco la situazione:
- Il traffico verso il server proviene da un'app mobile
- Tutto il traffico passa attraverso HTTPS
- Manteniamo le credenziali dell'utente crittografate nella memoria del dispositivo per registrare automaticamente gli utenti su ogni avvio di app
- Il timeout della sessione lato server è molto basso (pochi minuti) ed è fuori dal mio controllo
- Il DB è fuori dal mio controllo; Non posso aggiungere nulla al DB facilmente e rapidamente (sarebbe una bella sfida ottenere un campo DB se, ad esempio, volessi un token di sessione di lunga durata)
- Il traffico nell'app si verifica di solito nei batch
- Il tipico batch di traffico all'interno del timeout della sessione è costituito da poche richieste HTTPS
- Poiché il traffico proviene dall'app mobile, l'invio di richieste "keep alive alive" non è sempre possibile; se l'utente uccide un'applicazione e rilancia pochi minuti dopo (o riduce al minimo per alcuni minuti), non c'è possibilità di mantenere la sessione, e ho bisogno di relogin l'utente.
Quindi, lo schema di traffico tipico attualmente è:
#USER OPENS THE APP
POST /autologin -> response: [ok, here's the new sessionid]|[auth failure, maybe the password changed since]
#SUPPOSING AUTH WAS OK; USER BROWSES AROUND THE APP
POST /someAction1
POST /someAction2
POST /someAction3
#USER IDLE FOR A FEW MINUTES
POST /keepSession
...
#USER MINIMIZES THE APP
#USER RELAUNCHES THE APP, MAYBE SEVERAL MINUTES LATER, MAYBE NEXT DAY
POST /someAction4 -> response: sessionTimeout
POST /autologin -> response: [ok, here's the new sessionid]|[auth failure, maybe the password changed since]
#SUPPOSING AUTH WAS OK; USER BROWSES AROUND THE APP
POST /someAction4
...
Ad ogni modo, in media, devo inviare la richiesta di accesso abbastanza spesso una volta scaduta la sessione; percentuale significativa di richieste sono richieste di accesso.
Se invio login e password in ogni richiesta, posso
- elimina le richieste di
/autologinall'avvio - sbarazzarsi delle richieste di
/keepSessionogni pochi minuti mentre l'utente è attivo - elimina
/action- >/autologin- >/actioncombo in caso di sessione scaduta; giù dalla 3 richiesta a solo 1
Potrei sempre inviare sia il sessionid che la password di login +, quindi su sessionid per il riutilizzo del backend se ancora valido, altrimenti creare una nuova sessione usando login e password, e fare quello che volevo all'interno della stessa chiamata HTTP, senza la necessità per giocare a ping-pong tra frontend e backend.
Per riassumere, dal mio punto di vista:
Contro:
- Dovrei occuparmi del backend per non accidentalmente registrare le credenziali dell'utente in più gestori di richieste, non solo in uno (gestore di accesso)
- potrebbe aumentare il numero di richieste con login e passare in carico utile forse di un fattore di N = ~ 4,
Pro:
- il numero complessivo di richieste HTTP effettuate dal server è diminuito del 20% circa
- nessuna necessità di logica di frontend per mantenere la sessione utente; spara ogni richiesta con le credenziali. Se fallisce a causa di un problema di autenticazione, disconnetti l'utente.
Sapendo che il traffico è crittografato con HTTPS, ci sono dei lati negativi severi nel mio post-accesso-pass-and-pass sempre in corso?