Newsgroup: it.comp.www.php
Titolo: Sessioni (user univoco) e sicurezza

Mi trovo con questo piccolo "problema".
I miei committenti mi hanno chiesto di aggiungere ad un progetto già
quasi finito una funzionalità: il login univoco; ovvero: se dal
computer A si logga Tizio, Tizio non può loggarsi anche dal computer
B. Si tratta quindi di impedire i login multipli per lo stesso
utente.
Ho guardato un po' a giro e pare che il metodo migliore sia crearsi
una gestione delle sessioni tramite una tabella in MySQL creata ad
hoc. Ci sono altri modi, meno "invasivi"?
Seconda domanda: secondo voi, un login di questo tipo per un servizio
_a pagamento_ che però _non_ contiene dati sensibili (al di là della
pignoleria del committente) e soprattutto non è su connessioni sicure
e/o criptate, ha un senso?
-- 
.
Giorgia
.
Luke: "Io cerco un grande guerriero!"
Yoda: "Grande guerriero?!? Guerra non fa nessuno grande!"
.
(Per scrivermi, toglimi manette e catene)

 e/o criptate, ha un senso?
Si e no. Se non erro la legge sulla Privacy non parla di connessioni
sicure ma parla di accessi multipli.
-- 
I am what I am, I do what I can
Sei un newbie? Leggi questo 
http://url.repository.biz/go/3C
Vuoi supportarmi? 
http://url.repository.biz/go/3E
Do. Or do not. There is not try.

 sicure ma parla di accessi multipli.
Il punto è che la scrittura sul DB ogni volta che un utente fa girare
uno script, ovvero cambia pagina, mi sembra davvero eccessiva e
secondo me andrebbe usata solo quando si accede a dati davvero
sensibili, non per un portale su internet che fornisce, per esempio,
raccolta di dati esterni (video, musica) o simili. Non so se mi sono
spiegata. Qui non è che si accede a conti, carte di credito,
carrelli, o semplice posta (e molte caselle on-line non implementano
l'accesso esclusivo, ho controllato).
Insomma, mi sembra una cosa davvero inutile. Ovvio che quando lo
richiede il committente, bisogna farlo. Ma il committente ti
chiederebbe anche un progetto in grado di scrivergli la password
leggendogliela nel pensiero, se potesse!!! :°
Il mio problema è che questo progetto carica molto il server: dopo 
5 giorni di uso, c'è una tabella che già contiene 500 record (e deve
essere così!). Io vorrei evitare di caricare un server di un lavoro
che mi sembra inutile (tra l'altro il server è windows!).
Comunque pare che la scrittura su DB sia l'unico modo sicuro.
Il punto è che, per come la cosa va organizzata, se un utente non fa
il logout ma chiude brutalmente il browser (cosa che succede
_sempre_), la tabella nel DB usata per le sessioni resta _non_
aggiornata. Implementando una funzione nella pagina di login che,
ancora prima dell'effettivo login, acceda al DB e ripulisca tutte le
(finte) sessioni scadute, si rischia che l'utente distratto che per
sbaglio chiude il browser e tenta l'accesso pochi secondi dopo, se lo
trova sbarrato... ci sono portali che ti avvertono che qualcuno con
il tuo username è già connesso e che chiedono se vuoi "buttare fuori"
l'altra connessione, ma a me sembra davvero un'assurdità, tra l'altro
credo che scatenerebbe il panico tra gli utenti meno avezzi.
Io temo che tempo due settimane d'uso effettivo, e il mio committente
si renderebbe conto dello sbaglio solo dopo le lamentele degli
utenti.
Insomma, scusate per lo sfogo, ma sono partita da un progetto che
doveva fare "uno" e a forza di modifiche siamo arrivati ad un coso
immenso che fa "cinquanta", e io vorrei finirlo il prima possibile!!!
Anche perchè, a forza di modificare, il tutto diventa sempre più
ostico al programmatore, cioè a quella disgraziata della Giorgia!!!!
:))


 aggiornata. 
Se utilizzi session_set_save_handler la sessione viene aggiornata.


 Se utilizzi session_set_save_handler la sessione viene aggiornata.
Ho guardato su 
php.net
, ma non ho ben capito come quella funzione
risolverebbe il problema (a dire il vero non ho ben capito come si
usa, da 
php.net
). Ma il problema della chiusura del browser durante
quei 15/20 minuti della sessione, rimane. La "vera" sessione viene
chiusa, ma la "finta" sessione no, sia che venga usato un file, sia
che venga usata una tabella nel DB. 
Per quanto alla legge sulla privacy: se un utente usa la password su
altri computer oltre al suo, la colpa non è certo del
programmatore... i dati all'origine sono protetti. Come l'utente usa
la password e se la lascia a giro, sono fatti suoi!
O no? O_o


applicazione da due stazioni di lavoro;
(fonte - forse un po' datata? -
http://www.riksoft.com/indexok.asp?Goto=leg675min.htm
)
Tale norma (11) è valida solo per dati sensibili. Il mio progetto
contiene solo dei video, correntemente trasmessi alla TV. L'unica
cosa che può venir carpita all'utente, è quali video trasmessi su
rete nazionale gli sono stati assegnati e quale è l'username (perchè
appare nella barra: "Benvenuto $username!") ma _non_ chi è realmente
l'utente (niente nome, cognome, e-mails nè altro). (La gestione
dell'utente è solo lato-admin, i dati sensibili non sono nemmeno
visti dal cliente. Addirittura se vuole cambiare la password, deve
contattare l'admin che gliene assegnerà una nuova e
_telefonicamente_).
Comunque grazie per la segnalazione, non ci avevo pensato proprio per
niente :)
