On 08/06/2020 15:16, Enrico Maria Chellini wrote:
> Il giorno Mon, 8 Jun 2020 12:22:15 +0100
> Alessandro Pellizzari <
shur...@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.