A tutti, me compreso, consiglio un bel ripasso sul manuale
http://php.net/manual/en/security.da...-injection.php
perchè certe cose con il tempo sfuggono di mente.

Originariamente inviato da Sbidiguda
...
Forse dico una vaccata ma stà condizione mi sembra totalmente sbagliata.
...
La sintassi è assolutamente legittima. Il mancato utilizzo delle parentesi graffe può essere causa di problemi se si cerca di aggiungere altre righe di codice in uno dei due rami e ci si dimentica di racchiudere le istruzioni del ramo tra parentesi graffe (abbastanza frequente). Al più è opinabile l'utilizzo di $_POST nudo e crudo all'interno della condizione dato che potrebbe non esistere affatto. Ma diciamo che funziona lo stesso.

Al termine dell'IF ha la certezza che la variabile $nickname esiste e contiene:
1)una stringa vuota
2)un valore passato tramite post e reso innocuo per una query sql con mysql_real_escape_string

Al limite, avendo due assegnazione alla stessa variabile in entrambi i rami si poteva scrivere

Codice PHP:
$nickname = isset($_POST['nickname'])?mysql_real_escape_string($_POST['nickname']):''; 
Infine resta da chiedersi perché fare tutto questo se poi non si utilizza quel $nickname da nessuna parte.

Originariamente inviato da carlitosteam
...
Cortesemente mi aiutate a capire dove sta il bug ?
Ho notato che memorizzi le password in chiaro nel DB. Il tuo problema potrebbe essere in un'altra pagina in cui sono riusciti a fare una sql injection, e scaricare tutto il contenuto della tabella accessoadmin. A quel punto hanno avuto libero accesso in modo tradizionale avendo a disposizione ogni username e password.

Edit: OOOPPS! RoTeam dice le stesse cose. Sono d'accordo con lui!