PHP|Débutant :: Forums

Bonjour,

Par defaut mkdir ( http://fr2.php.net/mkdir ) n'est pas récursif. Ca veux dire que pour créer 'documents/'.$_SESSION['auth']->pseudo.'/'.$categorie il faut déjà que 'documents/'.$_SESSION['auth']->pseudo existe (ainsi que documents d'ailleurs). Il faudrait donc déjà vérifier ce point, ou activer l'option récursive (cf documentation)

Au passage, petite remarque de sécurité, ça serait une bonne idée de vérifier le contenu de $categorie via une regex (histoire d'éviter les  / ou pire encore les ../ qui permettraient de remonter l'arborescence).

@+

Bonjour,

Et PHP lui même ? Il est possible d'avoir cette information avec un script ne contenant que

<?php
phpinfo();
?>

@+

Bonjour,

Le foreach doublé n'est pas une bonne idée, cela va poser plus de problèmes qu'en résoudre.

Faisons "simple" :

le && correspond au and (a peu près, le and étant aussi possible d'ailleurs.

Ceci dit, vu le contenu de $match_product2 et de $match_product1, ça ne sera jamais truc, puisque je ne vois pas comment l'id du produit pourrait être dans les deux vu qu'ils sont différents !

Est ce bien un and ? Faut t'il que l'id du produit soit dans les deux $match_.... ou faut t'il qu'il soit dans l'un ou l'autre ? (auquel cas il faudrait remplacer && par || (ou or)).

NB : le mot clé return est utilisé dans une fonction, ce code est il bien dans une fonction ?
@+

Chipotons alors

En l'occurence si, mysql exécute très bien plusieurs requêtes à la suite, le séparateur étant ; un simple test en ligne de commande fonctionne très bien

Par contre il est vrai que les fonctions mysql/mysqli de php ne supportent à priori pas cette syntaxe, mon raccourci était un peu rapide. Reste que les injections SQL sont loin d'être une illusion, il faut s'en protéger....

@+

Bonjour,

Typiquement cela veut dire que le résultat de la requête n'est pas bon. Il n'y a en effet rien qui vérifie que $resultat soit bien une ressources mysql après la ligne

Du coup lors de l'appel à la fonction, il est possible que $resultat ne soit pas une ressource mysql, et paf, les warning.

Un truc du genre

J'ai déjà une idée du problème qui cause l'erreur SQL, mysql_query attends comme paramètre d'abord la requête et ensuite l'identifiant de connexion (facultatif d'ailleurs) là ou mysqli_query prend les paramètres dans l'autre sens, de mémoire.

@+

Bonjour,

Avant la piste pour la solution, quelques remarques :

- Si possible utiliser plutot les fonctions mysqli_* que mysql_* qui sont maintenant dépréciés (oui le site n'est pas à jour là dessus )
- Il est important de vérifier le contenu de $categorie avant de l'utiliser dans une requête SQL, car là ça pourrait être n'importe quoi, y compris une injection visant a supprimer toute la base
- Il doit manquer des guillemets dans le html des options du code du formulaire, mais bon pour tester ça ira

Concernant la solution, je pense que cela vient de la requête SQL list_bar, car elle fait appel à 4 tables mais n'en jointe que 3, et encore pas toutes entre elles. Ainsi on a une clause where sur le fk_id_categorie de posseder, mais rien qui ne relie cette table à la table bar. Du coup il n'y a pas limitation sur la sortie de la table bar, et le résultat contient toute la table...

@+

Bonjour,

PHP ne fait pas de mise en forme, c'est le travail des CSS (ou du HTML dans les temps anciens). Cf http://www.phpdebutant.org/article118.php pour se remémorer cela.

La solution n'est donc pas liée à PHP, mais aux CSS / HTML qui sont interprétés par le navigateur.

@+

non, y'a pire

Bonjour,

Réécrire le code n'est pas trop dans l'objectif de ce forum.

Par contre nous pouvons donner des pistes. Dans ce code, il me semble que ce qui est vraiment obsolète, c'est l'utilisation des fonctions mysql, il faudrait utiliser soit les fonctions mysqli, soit PDO.

Au passage, la requête faite n'est pas un modèle de sécurité, en général il vaut mieux selectionner le mot de passe et le comparer dans le code php que dans le requête SQL, pour deux raisons :

- On est jamais certain que deux mots de passe différents ne donneront pas le même MD5, même si c'est très peu probable (le MD5 n'est d'ailleurs plus recommandé, plus assez sur)

- Si quelqu'un trouve le moyen de faire une injection dans la requête, il ne passera pas le test du mot de passe (même si le mieux, c'est de ne pas avoir d'injection !)

@+

Bonjour,

Il y a je pense beaucoup à dire

- test2 utilise du PDO pour l'accès à la base de données, liste.php et connexion.php du mysqli, étrange d'avoir deux choix, il faut harmoniser et n'utiliser qu'une seule façon ! (de plus il y a un mysqli_connect dans connexion puis dans liste, ça commence à faire beaucoup)

- liste.php récupère l'id pour son select par un $_GET, hors sauf erreur de ma part, on appelle pas test2.php en donnant un id par l'url, il faudrait donc plutot alimenter $id via $donnees['ID_pick'].

- la requête présente dans liste.php selectionne ID_pick, donc la donnée qu'on lui fourni dans le WHERE, ce qui n'a que peu de sens (à part dans certains usages spécifiques et encore).

- et du coup, on réalise que la requête dans liste.php n'a pas de sens, la donnée est déjà sélectionnée dans la requête faite dans test2 via PDO, puisqu'elle sélectionne tous les champs - au passage c'est "mal" de faire comme ça, cf http://www.phpdebutant.org/article152.php

Il est donc possible de nettement simplifier le code sur cette partie.

Ou alors cette construction imbriquée relève de la mauvaise compréhension d'une autre problématique, celle de l'affichage de l'image car on a finalement que son contenu blob, ce qui mis tel quel dans la page ne fait pas d'image. Il y a alors deux "écoles" :

- Intégrer l'image en tant que src base64 dans le code html directement, simple à faire ici : cf http://www.bellami.fr/encoder-ses-images-en-base64 , mais cela peut vite faire des pages très lourdes, et à chaque rechargement de la page il faudra retransférer tout le html donc le poid des images

- Intégrer les images "à l'ancienne", dans ce cas ce n'est pas un include du liste.php qu'il faut faire, mais un appel externe, fait par le navigateur, via un html du genre

ce qui "complexifie" le code, fait faire plus de requêtes vers le serveur, mais à l'avantage que les images peuvent être mises dans le cache du navigateur.

@+

Bonjour,

Je pense que la lecture du tutorial http://www.phpdebutant.org/article112.php serait bénéfique.

"Au hasard" je dirai qu'il manque un ; à la fin de la ligne 37 (qui n'est pas la ligne 37 sur l'extrait du code ici, mais la ligne avant celle qui commence par $requete, ce qui me parait bien correspondre).

NB: ce n'est pas une base PHPMyAdmin mais une base MySQL

@+

Bonjour Bonjour,

Désolé pour le retard à l'allumage, je suis "un peu" débordé en ce moment (juste 2 trucs en parralèle encore tous l'aprem jusqu'a 18h après avoir enfilé le repas en 15min, plus la todo liste de la semaine qui est encore à 10 taches, plus les debuts de travaux - merci les chats - pour déménager, plus les gamins, plus....), je viens a peine de voir ce post sur la tablette dans un endroit que la politesse m'interdit de préciser plus.

Et je n'ai en effet pas encore expliqué cela.

Tout d'abord une info capitale, afin de refroidir un peu tout le monde : J'ai été banni pour pub aussi ! D'ailleurs MK aussi, mais il n'a pas dut s'en rendre compte. En fait, tout le monde était banni, les utilisateurs enregistrés, les nons enregistrés, en fait plus personne ne pouvait accéder.

J'ai dut intervenir en base de données directement, car je n'avais même plus l'accès à l'admin, c'est pour dire

Et c'est bien de la non faute à Maljuna Plus précisément, c'est bien lié a son action de bannissement, mais ce n'est pas de sa faute.

Maintenant prenez une aspirine, c'est l'heure de l'explication technique.

Ce forum, comme tous les sites sur nos infrastructures mutualisées, est servi par plusieurs serveurs, "planquées" derrière un répartiteur de charge (redondant, il a son jumeau prêt a prendre le relai si il se casse une jambe, mais ce n'est pas le sujet).

Du coup, par defaut, du point de vue du serveur web, la requete arrive depuis le répartiteur de charge, et non depuis l'ip du visiteur. Ce n'est pas super pratique, donc ça se corrige très bien avec une configuration du répartiteur de charge pour qu'il transmette l'ip du visiteur dans un header http, et coté serveur web un petit module et une configuration pour lui dire "ha ben l'ip, elle est là finalement". Ca fonctionne super bien.

Sauf quand on fait un peu trop de changement. Quelques ip qui changent, du coup, on met à jour une configuration existante sur un cluster un peu ancien. Jusque là, ça va. Puis on propage la configuration sur les autres cluster. Et c'est là que le drame intervient. Le cluster qui est derrière ce forum, entre autre, est plus récent. Et le module qui gère la traduction à légérement changé de nom. Pour ceux qui connaissent la configuration d'Apache, on utilise souvent de IfModule, avec le nom du module. Sauf que quand on met dans la configuration l'ancien nom d'un module, et bien forcément, il ne le trouve pas, et n'active pas la configuration.

Du coup, sur ce forum, tout le monde avait l'ip du répartiteur de charge. Les nouveaux inscrit avaient comme ip d'inscription celle du répartiteur de charge.

Quand Maljuna à posé le bannissement, il a suivi le mode standard, donc blocage de l'utilisateur et de son ip (pour éviter qu'il revienne avec un autre compte trop rapidement). Sauf que du coup, il a banni, sans le savoir, l'ip du répartiteur de charge.

Et paf, tout le monde était à la porte !

Du coup, j'ai changé les ip qui correspondaient au répartiteur de charge dans la base de données, et j'ai corrigé la configuration du module qui posait problème.

Et tout est enfin rentré dans l'ordre !

Donc tu le vois JC, vraiment rien de personnel là dedans, on appelle ça une catastrophe liée à une série de mauvaises manipulations et de quo-incidences.

La bonne nouvelle, c'est qu'on ne travaille pas dans une centrale nucléraire

En te souhaitant une bonne journée, et par la même occassion une bonne année

@+
ManicoW