ok,ma se devo usare crc per creare il checksum dei dati e ottenere così il token di controllo, con quello privato che ci faccio? crc non richiede in input solo la stringa su cui effettuerà il checksum?
Poi i dati che dovrò controllare ad ogni cambi pagina ( ip,user_agent, id_sessione) per creare il checksum, faccio senza salvarli in variabili di sessione, li recupero direttamente dentro il metodo in cui effettuo il controllo.
Fermo che ti stai incasinando con i codici di controllo .
1- token privato generazione una tantum a creazione dell'account ed eventualmente reset ogni x mesi ma e' una cosa che fai tu personalmente
2- "token attuale" ho sbagliato il nome sarebbe "checksum attuale"
Questo campo lo usi solo nel caso un cui non vuoi la query che genera il checksum da funzione sql. quindi qui hai 2 possibilità :
a) usi questo campo e lo generi e lo salvi a login. e poi esegui una query tipo :
select * from users where cehcksumAttuale = $checksum
b) NON lo usi e il controllo lo fai direttamente da funzione sql :
select * from utenti where crc( concat(sessionId,ip,userAgent,etc...) )=$checksum
Ora come vedi il codice privato e' una stringa random che generei tu sul server e utilizzi per generare il token da php in fase di controllo.
All'utente non spedire nessuno di questi dati ma solamente il sessionId ebbasta tutti questi codici servono per eseguire i controlli di accesso compressando le info in stringhe di hashing dipendenti in primis dai dati utente del server et in secundis dai dati che ricevi dalle requests.
il flow :
1- login
2- controllo user e pwd
3- se ok estrazione dati da database
4- lettura dati da request (user agent,ip)
5- avvio della sessione
6- recupero del session id
7- estensione dei dati utente con i dati della request
8- aggiornamento dati nel database
9- redirect a pagina del pannello di controllo
====>LA PAGINA DEL PANNELLO DI CONTROLLO O ACTION
1- inclusione dello script/classe di controllo sessione
2- controlli basilari di esistenza sessione e dati di sessione
3- CONTROLLI COERENZA
3.1- recupero dei dati dell'utente stipati in sessione
3.2- recupero dei dati dalla request
3.3- generazione $checksum a partire da dati utente recuperati al punto 3.1 + dati della request
3.4- controllo checksum con i dati nel database.
===> Se il controllo fallisce vuol dire che e' cambiato qualcosa e si necessita il relogin => (PROCEDURA DI LOGOFF -> [distruzione della sessione, pulizia eventuale dei dati nel database ] )=>redirect a login
3.5- altrimenti (opzionale)controllo tempo inattività ->tutto ok prosegui con l'operazione.
NOTE : in tutta questa trafile puoi anche inserire dei controlli a livello cookies ossia generare dei chesum o tokens da spedire come cookies per dei controlli aggiuntivi, questi controlli li puoi tranquillamente inserire in questa procedura.
Ulteriormente se temi session hijacking puoi crittografare i dati in sessione con una determinata chiave che dipenda dal crc dell'ip+sessionid+useragent .
Come vedi puoi opoerare in molti modi differenti ognuno con i suoi pro e contro.
Gud lac
E il token privato che utilità avrebbe? Dici che possa servire anche in un contesto dove c'è un solo utente e non c'è la possibilità di inserirne altri?
Per il resto tutto ok:
metodo per salvare i dati nel db:
e quello per controllare l'avvenuto login:Codice PHP:private function storeLog(){
$_SESSION['id_Session']=session_id();
$userAgent=$_SERVER['HTTP_USER_AGENT'];
$ip=$_SERVER['REMOTE_ADDR'];
$checksum=crc32($_SESSION['id_Session'].$ip.$userAgent);
$CurrentTime = date('c');
$sql="INSERT INTO accessi (id,ip,userA,loginTime,checksum) VALUES('','".$ip."','".$userAgent."','".$CurrentTime."','".$checksum."')";
$result=mysql_query($sql);
if($result === true)
return true;
else
return false;
}
Intanto grazie per gli aiuti ricevuti fino ad oraCodice PHP:public function isLogged(){
if(isset($_SESSION['id_Session']) === true)
{
$idSession=$_SESSION['id_Session'];
$userAgent=$_SERVER['HTTP_USER_AGENT'];
$ip=$_SERVER['REMOTE_ADDR'];
$checksum=crc32($idSession.$ip.$userAgent);
$sql="SELECT * FROM SiteAccess WHERE checksum=".$checksum;
$result = mysql_query($sql);
$error=mysql_error();
$row = mysql_num_rows($result);
if($row === 1)
return true;
else
return false;
}
else
return false;
}
Riprendo questa discussione senza aprirne una nuova perchè ho un problema sempre sul login.
Quando effettuo il login per la prima volta tutto ok, se faccio il logout e voglio riaccedere non entra. Il problema è che, anche se durante il logout faccio sia un session_unset che un session_destroy , quando il login viene effettuato una seconda volta , la sessione ha sempre lo stesso id della prima; di conseguenza vengono registrati due record sul database, con lo stesso checksum, e io nel controllo verifico che ce ne sia solo uno, altrimenti non logga l'utente .
Risolverò mettendo un session_regenerate_id al giusto posto, ma quello che mi chiedevo, è se è normale che dopo un session_unset e un session_destroy l'id della sessione sia sempre uguale.
Gli id di sessione sono dipendendenti da numeri generati random. La possibilità che generi un id doppio e' mooolto remota. Io quando accoppo le sessioni se riloggo 2 sec dopo ho un session id differente.
Il fatto che sia uguale puo' dipendere dalla mancata rimozione del cookie di sessione che tiene sempre il sessionId precedente, quindi quando riavvii la sessione php riutilizza il vecchio sessionId.
Controlla che il cookie PHPSESSID venga rimosso correttamente.
Inoltre il token ti rimane uguale poi' dipende da determinati dati che non cambiano.
Inolte fossi in te terrei solo 1 tabella dove i dati non si accodino.
I dati di login dello user devono essere sempre 1 recordset e mai piu' di 1, se vuoi loggare le operazioni usa una tabella esterna di logs non incasinare gli utenti etc...
In modo che hai 1 tabella che dice lo stato attuale del sistema e non diventa mai troppo corposa, poi hai la tabella di log dove spari dentro le operazioni una alla volta e se diventa troppo grande la backuppi da altra parte e poi la svuoti.
eh penso proprio che sia il cookie , perchè se cancello i cookie del browser tutte le volte questo problema non si presenta..
Dovrei cancellare il record col token corrispondente al logout , e al login fare una pulizia dei record eventualmente ancora salvati in precedenza ,nella tabella di controllo?
E per il cookie,secondo me, è meglio generare un nuovo session_id tutte le volte piuttosto che impostarne la durata.
Di default il cookie di sessione muore a terminazione della sessione.
Cmq nel caso a logout esegui manualmente la pulizia del cookie cosi' sei sicuro che va.
La tabella secondo me devi pensarla cosi'
users
//dati user
current_sessionId
current_userAgent
current_checksum
current_loginTs
//etc.....
a logout pulisci tali dati.
Inoltre il controllo di durata della sessione(dalla current_loginTs) lo esegui per controllare quanto tempo e' passato dall'ultima operazione eseguita e se sfora => logout.
Questa tabella la puoi integrare con una tabella di log operazioni
log_operazioni
id
id_user
session_id
userAgent
checksum
loginTs
operation
In questa tabella puoi stipare quello che ti pare ed usarlo per i controlli etc... cosi' facendo logghi le operazioni di cui vuoi tenere traccia senza dover impazzire a gestire i dati di sessione.
concordo sulla rigenerazione del sessionId , ma la durata la devi controllare se vuoi avere un determinato livello di sicurezza. Cio lo fai unitamente al sessionTimeout impostato nel tuo server. Le sessioni infatti scadono dopo x tempo sul server, in questo caso lancia un logout forzato o lo script relativo di gestione che logghi opportunamente il fatto.
Magari il server in locale su cui sto provando ha delle impostazioni strane, e nonostante la sessione venga terminata non mi elimina il cookie.
Io per adesso ho la tabella dove salvo :
id_accesso
id_sessione
ip
user_agent
timestamp
checksum
che uso per controllare il login, e in teoria qua dentro dovrebbe esservi salvato solo un record per volta,che viene eliminato al logout o al nuovo login(quando l'utente si logga ,prima di registrare i nuovi valori nella tabella, elimino tutti quelli esistenti).
Poi creerò una tabella con gli stessi campi, dentro cui i valori rimarranno salvati.
Facendo come dici te, non si andrebbe ad incidere pesantemente sulle prestazioni? Controllare ad ogni cambio pagina il timestamp salvato nel db e loggare ogni azione eseguita non appesantirebbe di molto l'esecuzione ?
ATTENTO : che chiudi il borwser e /o la sessione scade lato server ... quei dati non vengono cancellati.
Per questo ti dicevo di eseguire dei controlli come sopra.
se chiudo il browser e rieffettuo il login, prima di salvare il nuovo record, cancello tutti i precedenti, così ci sarà sempre un solo record nella tabella e il problema non si presenta
Permessi di invio
Rispondi quotando