Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > it.comp.www.php > #22822
| From | Alessandro Pellizzari <shuriken@amiran.it> |
|---|---|
| Newsgroups | it.comp.www.php |
| Subject | Re: verifica autenticazione best practices |
| Date | 2020-06-14 09:47 +0100 |
| Message-ID | <hkm6hiFl169U1@mid.individual.net> (permalink) |
| References | <20200608125019.20862d15@nntp.aioe.org> <hk6lb8Fcev0U1@mid.individual.net> <20200608161622.6d1dae58@nntp.aioe.org> |
On 08/06/2020 15:16, Enrico Maria Chellini wrote: > Il giorno Mon, 8 Jun 2020 12:22:15 +0100 > Alessandro Pellizzari <shuriken@amiran.it> ha scritto: >> In questo caso, salvi in sessione l'id dell'utente, e ad ogni pagina >> verifichi nel DB il suo stato. Se è disabilitato, cancelli la >> sessione, lo rimandi al login e magari gli mostri un messaggio "Il >> tuo accont è stato disabilitato". > > è ti è mai capitato sia necessario? Più che il caso dell'account disabilitato, che è abbastanza raro, mi è capitato spesso il caso di cambiare i permessi al volo, mentre l'utente era loggato. > per un sito web normale mi sembra sul paranoico caricando il server di > query inutili a ogni frammento di pagina da autenticare. Dipende dal sito web. :) Se non hai permessi o necessità di disabilitare utenti senza cancellarli dal DB, non serve. > anche perchè nel caso, lato amministratore potrei chiedere l'id della > sessione di un determinato utente e chiuderla anche quando l'utente è > collegato o sbaglio? Non c'è modo di sapere l'id di una sessione, se non dal cookie (o se hai un custom session handler e salvi l'informazione in un DB su cui puoi fare query) Rimuovere la sessione non impedisce che l'utente faccia login di nuovo e ne crei un'altra, quindi dovresti disabilitare il login in qualche modo e poi cancellare la sessione. Tutto si può fare, dipende da cosa ti serve. :) Per le prestazioni, dipende dall'architettura, ma la maggior parte dei DB hanno una cache in RAM dei risultati delle query, quindi spesso è sì una connessione al DB (che probabilmente hai già fatto per recuperare altra roba), e un po' di traffico su una socket, ma magari non tocca il disco se non la prima volta (che è il login...). Bye.
Back to it.comp.www.php | Previous | Next — Previous in thread | Find similar | Unroll thread
verifica autenticazione best practices Enrico Maria Chellini <bitit@bitit.it> - 2020-06-08 12:50 +0200
Re: verifica autenticazione best practices Alessandro Pellizzari <shuriken@amiran.it> - 2020-06-08 12:22 +0100
Re: verifica autenticazione best practices Enrico Maria Chellini <bitit@bitit.it> - 2020-06-08 16:16 +0200
Re: verifica autenticazione best practices Alessandro Pellizzari <shuriken@amiran.it> - 2020-06-14 09:47 +0100
csiph-web