Printable View
Ciao a tutti, ho un problema. Dovrei prelevare una variabile da una sessione.
Il tutto funziona così : l' utente effettua l' accesso a una pagina.
La pagina lo reindirizza alla home e inizia la sessione.
Da questo punto dovrei riuscire a far vedere il nome dell' utente nella pagina home. ( Benvenuto $myusername)
Grazie
Se non riporti i problemi o gli ostacoli che hai riscontrato è difficile darti un aiuto preciso. Il punto di partenza è la documentazione di PHP.
Dove vai a recuperare i dati di chi ha effettuato il login? sarà una tabella utenti con campi nomeUtente etc..
Una volta effettuato il login avrai una variabile di utenza esempio una select del tipo SELECT * from utenti where utente = '$nomeUtente';
Quel tuo $nomeUtente una volta effettuato il login dovrà essere inserito nella $_SESSION, ed imposti una variabile di sessione...esempio:
$_SESSION['nomeUtente'] = $nomeUtente;
Codice PHP:<?php
session_start();
if(!session_is_registered(myusername)){
header("location:login.php");
}
else{
$con = mysql_connect("localhost","","");
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
//Finds database
mysql_select_db("my_greenbowsoftware", $con);
$result = mysql_query("SELECT * FROM users where username="$_SESSION['username']";");
}
?>
<html>
<head>
<title>Greenbow Social</title>
<link href="style.css" rel="stylesheet">
</head>
<body>
<div class="navbar"><table><tr><td><img src="images/logo.png" class="logo"></td><td> </td><td><a href="logout.php"><h2>Logout</h2></a></td><td><p><?php echo $result; ?></p></tr></table></div>
<div align="center">
<br><br>
Bene per il codice, ma ancora non hai spiegato qual'è il problema che hai incontrato http://forum.it.altervista.org/image...e/icon_lol.gif.
Ad una prima lettura ci sono comunque alcune cose che vanno riviste:
Questa sintassi è deprecata in PHP 5.3.0 e rimossa in PHP 5.4.0. Va sostituita, ad esempio con:Codice PHP:if (!session_is_registered(myusername)) {
Codice PHP:if (!isset($_SESSION['myusername'])) {
Le funzioni mysql_* sono deprecate, vanno sostituite con mysqli o PDO.
La seguente "stringa"... non è una stringa, è un errore di sintassi:
Codice PHP:// Wrong
"SELECT * FROM users where username="$_SESSION['username']";"
// Correct
"SELECT * FROM users WHERE username='" . $_SESSION['username'] . "';"
Dovresti inoltre controllare che la query abbia successo (vedi mysql_query):
Codice PHP:$result = mysql_query("...");
if (!$result) {
die('Invalid query: ' . mysql_error());
}
Nella parte in HTML stai cercando di stampare la risorsa restituita dalla query, ovvero un oggetto opaco che contiene potenzialmente una (porzione di) tabella. Immagino tu voglia stampare solo il nome utente, quindi:
Nell'ultima riga, al posto di 'username', devi utilizzare il nome che hai assegnato al campo della base di dati in cui memorizzi il nome utente.Codice PHP:$user = mysql_fetch_array($result, MYSQL_ASSOC);
if (!$user) {
die('No users with given username');
}
...
echo $user['username'];
Dal brano di codice, sembra che tu stia utilizzando una tabella per il layout della testata del sito. Questo va contro le specifiche di HTML5, ed è pratica scoraggiata per vari motivi. L'uso di CSS è preferibile.
Essenzialmente il problema è che non trovò il modo di far comparire il nome utente quando qualcuno fa il login
Prova con le correzioni proposte: sono necessarie (e probabilmente sufficienti) a risolvere il problema.
Se uso questo codice, quando faccio il login, mi rimanda alla pagina di login. Quindi ho riutilizzato il mio codice originale.
Mantenendo il mio codice e utilizzando gli altri che mi hai consigliato, mi risulta questo: No users with given username;Codice PHP:if (!isset($_SESSION['myusername'])) {
Riguardo al primo errore, deduco che tu, nella pagina di login, stia utilizzando session_register. Anch'essa è deprecata, e andrebbe sostituita, ad esempio con:
Ma questo problema ora è secondario, meglio concentrarsi sull'altro.Codice PHP:$_SESSION['username'] = ...
"No users with given username" indica che la query ha restituito un insieme vuoto. Controlla che:
- L'utente con il quale cerchi di autenticarti esista
- Le credenziali siano corrette
- La query sia corretta
Si, utilizzo una session_register.
Le credenziali sono corrette, perché ho controllato tramite database.
La querula sembra funzionare.
Provo a modificare quello che mi dici e ti faccio sapere. Grazie
Uffa, è sbagliata la logica, oltre il fatto che session_is_registered è stata rimossa dal 5.4 quindi proprio non può andare a prescindere....Tu stai dicendo se la sessione a cui passo mysusername non è registrata quindi non ritorna true ok procedi al reindirizzamento a login altrimenti fai un else e imposti una query con un $_SESSION che non può esserci, è sbagliata proprio la logica....La logica come ti ho detto prima, fai la query passando i valori di username e password che un utente inserisce nel form di login farai la tua query per vedere se l'utente è registrato e se la password corrisponde a quell'utente registrato, una volta che hai un login CORRETTO puoi inserire dentro la SESSION le variabili dell'utente, che recuperi dai suoi dati, cioè il nome, il profilo, l'id e tutto quello che c'è nella tabella, la session fino a quando non viene chiusa tiene in memoria tutti i dati che gli hai passato.Ma non puoi fare una query di login con una session, non ha senso, prima fai partire la session, cioè session_start() se il login va a buon fine con i dati inseriti dall'utente nel form di login allora gli passerai i valori $_SESSION['username'] = $myusername, $myusername non è altro che il nome dello username nel form di login con il quale cerca di accedere.
Guarda in questo sito e analizziamo questo codice:
Gli sta dicendo se il valore che ti passo in POST dal form di Login è tutorialspoin e la password è 1234 allora accedi ed imposta delle variabili di sessione che sono lo username sessione valid etc....Tu glielo stai dicendo prima....La select di login non puoi farla con $_SESSION è proprio sbagliato a livello logico la select la devi fare con i valori in $_POST che recuperi dal form di loginCodice PHP:
if (isset($_POST['login']) && !empty($_POST['username'])
&& !empty($_POST['password'])) {
if ($_POST['username'] == 'tutorialspoint' &&
$_POST['password'] == '1234') {
$_SESSION['valid'] = true;
$_SESSION['timeout'] = time();
$_SESSION['username'] = 'tutorialspoint';
echo 'You have entered valid use name and password';
}else {
$msg = 'Wrong username or password';
}
poi controlli che i valori in post, che si presuppone siano nome utente e password corrispondono effettivamente ad un utente registrato a quel punto quando il login è andato a buon fine imposti la SESSIONE....Hai capito adesso?
http://www.tutorialspoint.com/php/php_login_example.htm
Ho un sospetto, potresti per favore inserire una stampa
e riportarne il risultato? (Normalmente le "prove con le echo" sono poco professionali, ma vorrei fare un rapido test).Codice PHP:echo "username: < " . $_SESSION['username'] . ">";
fractal, la logica è corretta, il nostro greenbowsoftware ha già una procedura di login, e per vari motivi, preferisce non inserire tutti i dati dell'utente nella sessione, ma solo il nome utente, e recuperare gli altri dati on demand. Certo non è l'unico modo di fare le cose, ma non è poi una cattiva idea, evita di esporre i dati dell'utente in una sessione, mitigando gli effetti dannosi di Session Hijacking e Session Fixing (ancora meglio sarebbe non inserire nemmeno il nome utente, ma usare un meccanismo basato su token).
Finalmente... Ce l'ho fatta!!!!
È bastato unire lla pagina di home con il quella di verifica di login e tutto si è risolto
Grazie mille a tutti :thumbsup:
Ma stai scherzando Zanella, la logica non è corretta per una session di Login...hai letto il codice.Va behh allora è corretta...La logica di un login è la seguente
Inserisco i campi nome utente e password in un form html
recuperoi dati in una pagina php con dicitura $username = $_POST['username'], $password = $_POST['password']
Faccio una select del tipo SELECT * FROM UTENTI WHERE USERNAME = '$username' AND password= '$password'
Se la query ha UNO ED UN SOLO RISULTATO
Allora login effettuato E SOLO IN QUESTO MOMENTO IMPOSTO LE $_SESSION....
Ohh per piacere ehhhh, non diciamo fesserie....è sbagliata la logica.
Se poi gli funziona vuol dire che c'è qualcosa che non quadra non è ordinato il codice, non può fare un reindirizzamento a login oppure rifà la select con un $_SESSIOn, ma scherziamo aooo la matematica non è un'opinione.
PS: È bastato unire lla pagina di home con il quella di verifica di login e tutto si è risolto
Grazie mille a tutti
Ma cosa vuol dire? allora la verifica di login effettua la verifica e imposta le variabili di sessione e poi cosa fai?
rifai la select di login in una pagina home?
Non è corretto a livello logico, la verifica si fa una volta se va tutto bene nelle altre pagine crei una funzione di CHECKlOGIN cioè if isset $_SESSION['valid'] ok fai vedere le pagine altrimenti NON HAI EFFETTUATO IL LOGIN MA NON si rifà la select...Va behh fa come ti pare...Ciao
Tutto è bene ciò che finisce bene! http://forum.it.altervista.org/image...icon_smile.gif
fractal, non dico che la procedura da te proposta sia sbagliata, al contrario, è corretta... però quella da te descritta è la procedura di autenticazione, che greenbow ha già.
A lui interessava la procedura di recupero di dati, assumendo di aver già effettuato l'autenticazione http://forum.it.altervista.org/image...icon_smile.gif
Ohhh allora parlo arabo a lui le cose non funzionano perchè sta facendo dei MISCUGLI sta facendo un MINESTRONE, la session_start() fa tutto lei quindi nel momento in cui ha effettuato il login ed è partita la sessione i dati sono automaticamente salvati in $_SESSION, var_dump($_SESSION), ma il problema qui è un altro....non hai letto il codice allora, lui fa un reindirizzamento a login a fa una select * from utenti where username=$_SESSION è questo che è illogico....Uffa, va behh fate come volete che mi frega.
Ps:Ma è sbagliato, il recupero dati di un utente li inserisci nella session, non rifai una select per recuperare dati che dovresti aver già recuperato dalla tabella username...Capisci che non si programma così, la select dalla tabella username la si fa una volta sola e si recuperano i dati che ci servono e si inseriscono in variabili di sessione....va behh programmate come volete che mi frega.
Facciamoci a capì, se un utente è loggato tu rifai questa select
E questa select cosa dovrebbe recuperare che non può essere recuparato dalla prima select di login ed inserito dentro una variabile di sessione?Codice PHP:
$result = mysql_query("SELECT * FROM users where username="$_SESSION['username']";");
Capisci che stai facendo doppio lavoro?....La tabella users si presuppone che abbia tutti gli utenti(ovviamente si presuppone che l'utente sia univoco) quando fai il login non fai la select dalla tabella users?Se si allora questa select che hai impostato è doppia...Questo è l'errore e non va bene, tu devi fare un array di sessione e dentro l'array metti tutti i valori che ti servono nel software e non stai a rifare le select dalla tabella utenti....Per fare il checkLogin farai una funzione che metterai ad inizio di ogni pagina e dentro questa funzione dirai :
Mannaggia a sti programmatori :)Codice PHP:
function checkLogin(){
$server = $_SERVER['HTTP_HOST'];
if (!isset($_SESSION['datiUtente'])) {
echo('Non sei loggato, clicca il link sottostante per loggarti :' . '<br>');
print("<a href='http://$server/MvcWebLog/view/login.php'>Login</a>");
exit ;
}
}
Questo è un modo di fare le cose. A seconda del contesto può essere il modo migliore: leggere tutti i dati associati all'utente al momento del login, memorizzarli in uno stato globale (la sessione) e leggerli al bisogno. Ci sono pro e contra. I pro sono sicuramente la facilità di implementazione, i contra sono i rischi di Session Fixing e Session Hijacking, l'inconsistenza tra sessione e base di dati, impossibilità di memorizzare dati non serializzabili e maggior consumo di memoria.
Un'alternativa, quella utilizzata da greenbow, consiste nel memorizzare nella sessione soltanto un token. All'autenticazione vengono controllati solo il numero di match di username e password, senza recuperare nessun campo (operazione, dunque, più snella che nel caso precedente), e i campi che eventualmente serviranno saranno recuperati on-demand al bisogno.
In questo modo si evita di recuperare dalla base di dati informazioni che non saranno mai usate durante la sessione. Ovviamente questo non viene gratis: eseguire n operazioni "piccole" anziché una grande può rendere la latenza per l'accesso alla base di dati dominante sui tempi di esecuzione (benché un uso intelligente della connessione alla base di dati possa abbassare queste latenze).
Un altro vantaggio è che l'informazione non viene mai duplicata: solo la base di dati contiene l'informazione, rendendo impossibili inconsistenze di sorta. Inoltre, non c'è il vincolo sui dati non serializzabili.
Caso d'uso 1
Per ogni utente vengono memorizzati nome utente, (password) e altri dati (non sensibili né identificativi). Si assumono trascurabili danni causati da Session Hijacking o Session Fixing. Il nome utente e gli altri dati sono usati spesso nelle pagine del sito.
In questo caso si verifica che la soluzione proposta da fractalcosmo è ottima.
Caso d'uso 2
Per ogni utente vengono memorizzati nome utente, (password) e molti altri dati, potenzialmente sensibili ed identificativi, di dimensione significativa (ad esempio la biografia completa dell'utente in formato non plain text, una foto in alta definizione) e collezioni di altri dati (ad esempio l'insieme di tutti gli articoli scritti dall'utente). I danni causati da Session Hijacking o Session Fixing sono valutati come non trascurabili. I dati memorizzati vengono usati sporadicamente durante una sessione di lavoro, e quasi mai tutti assieme.
In questo caso l'alternativa (magari migliorata con l'uso di token per la confidenzialità dei dati ed altre strategie) è ottima.
Ci sono anche strategie ibride: memorizzare alcuni dati dell'utente in una sessione e recuperare dinamicamente quelli più pesanti o acceduti meno frequentemente.
Chiaramente la scelta spetta non spetta a noi, la cosa più ragionevole che possiamo fare è mostrare entrambe le alternative evidenziandone pregi e difetti e lasciare che siano gli interessati a scegliere in base alle loro esigenze.
Ma dai Zanella, scusa se mi permetto ma non sembra che tu sia molto esperto ma fai molte ricerche su google, e così facendo sbagli molte cose, la session ha un autoregenerate ID di sessione che si rigenera ad ogni sessione, ogni sessione ha una string session UNIVOCA DI 32 CARATTERI, quello che dici, scusa se mi permetto , è FUFFA, chi programma sa come fare la sessione e soprattutto previene sia la session hacking che la sql injection....Quindi per piacere non facciamo o diciamo cose che non sono reali, e te lo dice uno che programma in PHP otto ore al giorno per lavoro.Ciao
Anzi a dirla tutta proprio la select scritta in quel modo non ha proprio senso è proprio un orrore, se tu parli di prevenzione della session hacking avresti dovuto dire che la select si scrive
SELECT * FROM utenti WHERE username = ?
Chiuso....Quindi per piacere, non sopporto i saputelli.Io gli do un consiglio non perchè sono ESPERTO ma perchè volente o nolente lo faccio per lavoro, quindi credo sia giusto dare i giusti consigli di programmazione , poi uno fa quello che vuole programma come vuole ci mancherebbe, ma se tu tiri fuori la session hacking allora hai sbagliato a priori e dovresti essere d'accordo con me a prescindere perchè vedere una select scritta in quel modo, è definito ORRORE, sembra che vuoi fare solo polemica.
Sull'uso dei prepared statement, sono senza dubbio un'ottima idea, assai migliore della grezza query proposta nei precedenti messaggi, ed è bene che siano stati citati. Sono un valido strumento di protezione contro SQL Injection, non direttamente Session Hijacking.
Purtroppo essi non sono supportati dalle API mysql usate dall'autore della discussione, ed io non posso certo imporre l'uso di mysqli né PDO.
Riguardo al Session Hijacking, riconosco sia la parte in cui sono stato più vago, volutamente, trattandosi dell'aspetto più articolato.
Benché le sessioni di PHP siano considerate sicure (se supportate da HTTPS, session_regenerate_id, salvataggio su cookie anziché URL ed utilizzo di HttpOnly), la loro memorizzazione non lo è.
Segue che vulnerabilità del servente (sul quale il programmatore non ha potere) possono portare un attaccante ad accedere, lato server, al contenuto della sessione: un problema, se questa memorizza dati confidenziali. L'uso di un token è una tecnica per mitigare i danni.
Ci sono esempi più semplicisti in cui si abusa del session_set_save_handler, salvando il contenuto della sessione lato client, un invito a nozze per Information Disclosure e Session Hijacking.
Vero è che sono casi limite, motivo per cui restai vago sull'argomento, ma se mi si accusa di "dire FUFFA" e "dire cose che non sono reali"... eh beh, ci rimango un po' male! http://forum.it.altervista.org/image...e/icon_lol.gif
Guarda che stai facendo un po di confusione...a parte che una volta che uno é entrato nel tuo sito non ha certo bisogno della session username o session campo tabella per recuperare dei dati ma il danno é già stato fatto quindi devi prevenire...ma tralasciando questo stai confondendo sosa vuol dire il tuo articolo quando parla di salvataggio di variabili di sessione...inserire nella session i dati che ti servono nel software non é certamente un problema di hacking mentre non inserire session regenerate id quello si che é un problema...fare in login senza inserire una funzione per impedire gli attacchi continui quello si che é un problema di sicurezza fare un login senza comparare stringhe in case sensitive quello si che é un problema di hacking...ma non di certo una volta entrato crearti il tuo array di sessione fai un po di confusione...poi non ho capito cosa centrano i token ?il token in php é un array a tre elementi nome del token riga etc... Il token non é altro che un operatore che parsa il tuo file e restituisce informazioni su tutto quello che c'é scritto nel file....tu sei venuto a dire che per avere piu sicurezza é buona norma fare le select nella tabella users 50 volte senza bind tra l'altro e dici per avere per forza ragione che se fai 50 select per recuperare valori dell'utenza allora previeni l'hacking e metti articoli che mi sa che sincerame te non hai capito...il salvataggio in file o sul db della session non é certo il nostro caso...comunque la finisco qui...ciao notte
Un attaccante che ha ottenuto l'accesso al filesystem (e quindi al contenuto delle sessioni) non ha necessariamente accesso al contenuto della base di dati.Citazione:
a parte che una volta che uno é entrato nel tuo sito non ha certo bisogno della session username o session campo tabella per recuperare dei dati
Da qui l'idea di memorizzare nella sessione solo un access token, e non dati confidenziali. Idea non sempre ottima, ma valida in alcuni contesti.
Mi riferisco a meccanismi di Token Based Authentication, non ai token di PHP.Citazione:
poi non ho capito cosa centrano i token?
Non ho mai detto che sia buona norma, ho parlato piuttosto di alternativa. La "maggior sicurezza" non deriva dal "fare 50 select", bensì dal mantenere i dati sempre racchiusi nella base di dati, senza duplicarli nel filesystem. Spesso precauzione superflua, allo sviluppatore spetta la decisione finale.Citazione:
tu sei venuto a dire che per avere piu sicurezza é buona norma fare le select nella tabella users 50 volte senza bind tra l'altro
Non ho mostrato l'uso di prepared statement perché l'autore della discussione usa le API mysql, in cui essi non sono supportati.
Mitigo alcuni danni causati Session Hijacking, la prevenzione è un argomento separato, ortogonale rispetto al confronto tra due approcci per la memorizzazione dei dati in una sessione (in fin dei conti di questo si tratta: un approccio eager ed uno lazy, nulla di più).Citazione:
se fai 50 select per recuperare valori dell'utenza allora previeni l'hacking
In ogni caso, non grazie all'aumento del numero di query, quest'ultimo è una mera conseguenza della strategia adottata.
In termini espliciti, l'approccio proposto segue la falsariga di OAuth 2.0, in cui il servente che gestisce l'autenticazione è separato da quello che gestisce la/e risorsa/e, dunque il processo di autenticazione non memorizza i dati dell'utente, ma genera un token.
A scanso di equivoci, questo non significa che l'approccio proposto implementa esaustivamente OAuth, piuttosto che ne trae ispirazione.
Zanella guarda io non è che voglio fare polemica ma secondo me stiamo dicendo due cose diverse, creare una sessione sicura ha determinati meccanismi che secondo me non c'entrano con quello che stai dicendo tu:
https://wblinks.com/notes/secure-ses...nagement-tips/
creare una sessione e recuperare un username ed un profilo del tipo:
Non implica un problema di sicurezza, secondo me stai creando un pò di confusione, abbiamo intanto capito che come token intendi una stringa di 32 caratteri che identifica la session, in parole un SID, per tutto quello che riguarda il lato javascript dovresti sapere che in PHP uno sviluppatore si preoccupa di inserire sempre degli strip_tags nella variabili che invia al server...etc..etc..Codice PHP:
$datiUtente = array('idUtente'=>$idUtente,
'username'=>$username,
'profilo'=>$profilo,
'stringaLogin' => $stringaLogin);
$_SESSION['datiUtente']=$datiUtente;
Qui siamo partiti discutendo che l'utente sopra fa un login e subito dopo rifà una select con un $_SESSION senza tra l'altro impostare un ID di sessione e controllarne l'ID, questa procedura non è per niente sicura e tra l'altro non è per niente elegante(nella mia opinione sia chiaro), ovviamente non inserisci la password dentro i dati di sessione, ma piuttosto la nascondi in SHA1 ma dire che fare continuamente delle select per recuperare ad esempio il profilo di un utente è conveniente permettemi di dire che non è vero, piuttosto il controllo dell'IP il controllo del referer.
Comunque io non so cosa dire, nel mio array di sessione ci sono 4 campi come puoi ben vedere tutto il resto è fatto via server il cros site scripting il CSFR, i controlli lato server ad ogni salvataggio....Ovviamente per i miei progetti personali perchè al lavoro viaggio in VPN quindi problemi non ce ne sono...Comunque va behh at salut buona domenica, Ciao.
Ho applicato tutte le modifiche che mi avete detto e ce l' ho fatta. Così non sembrerá che vi stia "stuprando il php". Grazie a tutti.