Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

verifica autenticazione best practices

9 views
Skip to first unread message

Enrico Maria Chellini

unread,
Jun 8, 2020, 6:55:00 AM6/8/20
to
buon di.. tanto per rimettere in discussione le mie conoscenze, per
proteggere un area riservata di un sito, io avevo impostato una
verifica della sessione.

come nei seguenti link:

https://stackoverflow.com/questions/8119496/php-secure-session-login-best-practice
https://www.quora.com/How-do-I-make-a-secure-login-in-PHP
https://itsourcecode.com/free-projects/php-project/secure-login-page-using-phpmysql/


ovvero:
1# dal login creo una sessione
1# nelle pagine riservate verifico se la sessione è avviata

if ($_SESSION['loggedin']) {
// user is logged in
echo 'Welcome ' . $_SESSION['name'] . '!';
} else {
// user is not logged in, send the user to the login page
header('Location: index.html');
}
https://www.quora.com/How-do-I-make-a-secure-login-in-PHP

se no ritorno alla form di login.

secondo voi è sufficiente o si dovrebbe in ogni pagina riverificare la
query idutente, utente, password, etc..?

Grazie
Enrico

Alessandro Pellizzari

unread,
Jun 8, 2020, 7:22:19 AM6/8/20
to
On 08/06/2020 11:50, Enrico Maria Chellini wrote:

> secondo voi è sufficiente o si dovrebbe in ogni pagina riverificare la
> query idutente, utente, password, etc..?

La sessione è salvata sul server. Il client ha solo l'id della sessione,
e passa solo quello.

Per verificare ogni volta username e password dovresti salvarli in
sessione e rifare la query ogni volta, il tutto server side, mentre il
client ha sempre e solo l'id di sessione e non ti passerà niente altro. :)

Secondo me non vale la pena riverificare l'utente, tranne in un caso: se
vuoi poter disabilitare l'utente (o se vuoi poter cambiargli i permessi
mentre è loggato).

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".

Bye.

Enrico Maria Chellini

unread,
Jun 8, 2020, 10:21:04 AM6/8/20
to
Il giorno Mon, 8 Jun 2020 12:22:15 +0100
Alessandro Pellizzari <shur...@amiran.it> ha scritto:

> On 08/06/2020 11:50, Enrico Maria Chellini wrote:
>
> > secondo voi è sufficiente o si dovrebbe in ogni pagina riverificare
> > la query idutente, utente, password, etc..?
>
> Secondo me non vale la pena riverificare l'utente, tranne in un caso:
> se vuoi poter disabilitare l'utente (o se vuoi poter cambiargli i
> permessi mentre è loggato).
>
> 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?

per un sito web normale mi sembra sul paranoico caricando il server di
query inutili a ogni frammento di pagina da autenticare.

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?


Enrico

Alessandro Pellizzari

unread,
Jun 14, 2020, 4:47:48 AM6/14/20
to
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.

0 new messages