Salut les geeks  
 
me voila de retour avec mon problème de connection sécurisée.
 
j'ai pas mal avancé depuis la dernière fois voici ma page de login : (secretdb.php)
 

 
la page qui vérifie le login et le cas échéant permet de retourner sur la page de login: (logclient.php)
 

 
et le .php avec les identifiants/password admin, dans un dossier pour en préserver le code (est ce que c'est une bonne méthode aussi?): (connexiondream.php)
 

 
voila donc tout semble marcher comme sur des roulettes seulement.. quand le login/mdp est bon.. l'utilisateur reste sur la page de login..  
 
je voudrais faire un lien de la page de login vers un index du site par exemple avec les différents menus accessibles à l'utilisateur loggé.
mais je ne sais pas comment faire.. implémenter un header.. mais qu'est ce qui empeche l'utilisateur mal intentioné de se connecté directement à l'index avec le menu sans passer par le login en recopiant simplement l'url?  
 
merci d'apporter des réponses à mes interrogations

Bein dans toutes les pages du site il faut regarder dans une variable de session si le visiteur est bien passé par la case identification et sinon le balancer sur la page de login.

 
en pratique ca donne quoi?  
 
j'ai une bd nommée auth, avec pour table ;autorized_user; composée des champs : user_id , name et password.
 
user_id est en autoincrement
 
je peux me servir d'user_id pour identifier l'utilisateur? (c'est le but je sais mais j'ai pas encore tout bien saisi )
 
merci

... J'avais pas lu le script que ta pompé ...  
 
Vite fait, on dirait que quand on se log avec succès on affect $_SESSION['logclient_ok'] = "oui";
 
DONC ... à priori ... dans index.php il faut qu'on début tu vérifie que $_SESSION['logclient_ok'] == "oui" et pas $_SESSION['logclient_ok'] = "non"  
 
Après bon, ça répond juste à

oki thx mate c'est un grand pas pour l'humanité que tu viens de me faire franchir là

je pète un câble la .. je suis bloqué je sais pas quoi faire

pkoi il marche pas mon index?
 

 
edited!

C'est "==" et pas "=" ligne 2

voui merci j'av vu
 
mais ca n'empeche .. tu sais comment faire un boutton pour me délogger?

le minimum :
 
 

 
ds logout.php :

argh mais nan.. je dis n'imp.. j'avais pas essayé en corrigeant le = par ==.. du coup now il m'affiche go pve nub!.. preuve que je suis pas log.. pourtant je me suis log.. donc..comment faire pour que le $_SESSION['logclient_ok'] = "oui" soit... comment dire.. activé.. pour un temps donné disons 20 minutes.. déja il faut un champ logclient_ok en autoincrement dans ma base de donnée auth(orisations) ou rien a voir?

 
merci c'est toujours ca de pris, meme si en fait je suis pas log..  
 
enfin la variable de session $_SESSION['logclient_ok'] = "oui" n'est pas passé. pourquoi? je ne le sais pas encore  

au début de chaque page il faut un session_start();
 

merci à toi au grand maître du php.. je sens que ca vient!!!

t1 et dire que j'étais bloqué à cause d'un malheureux session_start..    
 
enfin bref la ca marche je vous remercie tous les 2 les gars c'est du bon boulot, vraiment ca faisait un baille que j'étais bloqué dans l'avancement de mon site à cause de cette histoire d'authentification.. ca fait du bien quand les messages d'erreurs s'arretent un peu

 
Une magnifique faille d'injection SQL ici    c'est presque identique a un exemeple de ce qu'il ne faut surtout pas faire ^^
 
Réfléchi 2 secondes la dessus.  
 
Si dans le $_POST['name'] j'ai l'immense idée de passer ca comme valeur => admin'--
 
 
ben je me connecte tranquilement sans memeconnaitre le mot de passe et ce avec n'importe quel utilisateur  

C'est vrai que c'est un classique ... En même temps j'ai jamais reussi à la faire fonctionner ce trick sur mes sites, pê parceque le magic_quote est toujours activé ...

 
c'est vrai que c'est de plus en plus souvent que l'on trouve les magic quotes activé
 
mais bon, c'est pas une raison  

 
+4000002.
J'ai proposé justement un script ici permettant d'éviter ce genre de chose mais certain ont crier au loup   J'ai lu un article (sur le magasine nexen) disant que même avec addslashe & cie il est possible de faire des injections au final j'ai raison et *ma méthode empeche à 100% l'injection sql vu qu'il n'y a pas de contacte directe avec la db.
[flambe]
 *   Oui je sais je me la raconte...  
[/flambe]
 
Edit :  
Article sur l'injection SQL : http://www.directionphp.biz/a_la_une.php?mois=2005-10
Tuto pour eviter l'injection : http://forum.hardware.fr/forum2.ph [...] 1#t1097790

Et elle est où ta méthode ???

J'ai édité, j'ai placé les deux liens

super, je vais passer le reste de mes vacances à essayer de réitérer l'exploit de ton prof

Si tu regardes l'article tu comprendras par quoi il est passé .

l'article ds DirectionPHP ?
je l'avais deja lu, mais ca m'avait vraiment ennuyé  

T'inquiète, ça été pareille pour moi  

 
T'es trop dur   j'ai pas envie de le lire
 
Perso j'y connais rien en bidouille mais le coup de ton prof me parait être juste un bug surement corrigé depuis belle lurette.  
Parce que sinon, ça voudrait tout simplement dire que 99% des site web sont faillibles. Une fois qu'on a trouvé quels caractère passent à la trape ... c'est finis on peut l'appliquer partout.
 
Maintenant, j'suis pê mmulti-burned mais si on veut être tranquille, un peu moins bourrin et si on est avec mylsq ( = pas de requetes multiple ) on peut pê préférer mixer les deux, faire le select avec le mysql_real_escape($P_OST[login]) et se servir du php pour vérifier que le pass correspond bien non ?

C'est pas un bug du language parce que ceci est valable sur n'importe language web. jsp, php4 ou 5, asp, asp.net ... c'est juste que c'est une mauvaise habitude de developper. Et effectivement énormement de site possede cette faille. Tu verrais sur l'article que meme le mysql_real_escape n'est pas suffisant.

Il nous manque toujours le "proof of concept"

non, sa méthode fonctionne (si elle fonctionne effectivement) dès que l'on utilise une donnée venant de l'extérieur dans la requète.

 
Non c'est exactement pour cette raison que j'ai créer la table auth  > autorized_user, seuls les login et mdp présents dans cette table fonctionnent.
 
Ou alors j'ai pas compris ce que tu voulais dire expliques moi

en même temps c'est vrai que mon magic_quote est sur on

injection sql = on rajoute du code sql dans la requette à l'insut du développeur.
 
Par exemple avec un $_POST[ 'name' ] égal à "' or ''='" et $password qui a la même valeur t'obtiens comme requette :

Cette requette a la superbe capacité de te retourner l'ensemble des lignes de ta table. Fait donc le test sur ton site, tu véras, c'est miraculeux.
 
EDIT : Même si t'as magic_quote sur on, il vaut mieux développer en prévoyant dés le départ que magic_quote puisse être mis à off. Ca oblige peut être de rajouter quelques lignes de codes mais ca t'évitera des ennuis le jour où ce réglage changera à cause d'un changement d'hébergeur ou de serveur ou à cause d'une mise à jour de php.

Dans l'une de mes pages qui proposent un résultat multiple (titre, auteur, acteur etc...)
je souhaiterais faire que le titre soit clickable.
 
j'en suis la pour l'instant mais ca ne fonctionne pas:
 
°°
$query = "SELECT * FROM movies WHERE ".$searchtype." LIKE '%".$searchterm."%'";  
 
$result = mysql_query($query) or die("Query failed" );  
 
$num_results = mysql_num_rows($result);  
 
echo "<p>Nombre de films trouvé: ".$num_results."</p>";  
$i = 0;  
while($row = mysql_fetch_array($result,MYSQL_ASSOC))  
{  
  echo "$i : <a href='"+mysql_result($result,$i,"titre" )."'>";
  echo "Le site web de ".mysql_result($result,$i,"titre" )"."
  echo "</a><br>";
  echo '</strong><br />realisateur: ';  
  echo stripslashes($row['realisateur']);  
  echo '</strong><br />acteur: ';  
  echo stripslashes($row['acteur']);  
  echo '</strong><br />annee: ';  
  echo stripslashes($row['annee']);  
  echo '</strong><br />genre: ';  
  echo stripslashes($row['genre']);  
  echo '</p>';  
}
 
mysql_free_result($result);
mysql_close($link);
°°
 
alors que ca marche avec cette ligne:
 
°°
echo "<p><strong>".($i+1).". titre: ";  
echo htmlspecialchars(stripslashes($row['titre']));
°°
 
mais bien sur je n'ai pas de lien..
 
j'imagine qu'il y a une technique plus simple malheureusement je ne la connais pas encore..
 
(les °° c'est histoire de délimiter)

 
 
j'ai beau rentré ce que tu me dis à savoir : "' or ''='" dans login et "' or ''='" dans mot de passe rien n'y fait : Accès refusé

Ca serait surement mieux de mettre une adresse comme lien plustôt que de mettre le titre du film. Par ce que le navigateur, il est pas trés intéllo dans son genre : il cherche le fichier à l'adresse indiqué même si elle correspond à rien et il comprendra jamais que le bon lien c'est "<a href='http://mondomaine.com/toto/detail.php?id=98675'>" quand tu lui indique "<a href='le nom de la rose'>".

Si tu prévois pas le coup dés maintenant, on en reparlera quand tu changeras d'hébergeur.

 
nan le truc c'est que je veux en faire un lien vers une autre base de données.

Et alors? Même si tu voulais faire un lien vers une page donnée d'un fichier pdf, il faudrait quand même fournir un lien valide vers une page ou un fichier.
Aprés que l'autre page demande le titre, l'id ou encore autre chôse, c'est une autre histoire et ca demande juste à adapter le lien ... lien qu'il faudra quand même écrire selon les régles.

 
 
La méthode que tu suggères (à savoir lire TOUS les enreg) pour se connecter, c'est nawak. Je ne conseille à personne de l'utiliser.
Avec mysql_real_escape, il n'y a aucune chance d'injecter du mysql...
A la limite, si tu es vraiment parano, tu fais un filtre pour ne conserver que les caractères alphanumeriques aA-zZ 0-9.

Je suis pas parano c'est ce qui a été fait sous mes yeux  + il y a eu un article sous le site de nexen.  
"Tous les enregistrements"  et alors c'est que trois champs. Généralement il y a pas 36 000 comptes, il va pas faire tomber le serveur ou mysql va pas te cracher au visage pour ça.  
Alors ne conseiller à personne pour un gain gagner de <1% contre une sécurité qui garantie à 100% l'injection SQL, crier au loup pour ça et que le reste du code soit à dégueuler il faudra se remettre en question.  
 
Au final, c'est pas déconseillé mais un choix.