J'en vois... huit paires, celles qui englobent les isset.
Tu devrais faire une fonction qui teste la présence de toutes ces clés dans le tableau $_POST. Et ne pas mettre des parenthèses inutiles.
c'est a dire....
Si tu ne sais pas ce qu'est une fonction, je t'encourage à l'apprendre : <http://fr2.php.net/manual/fr/language.functions.php>. Ça te fera gagner du temps.
À quoi ça sert de supprimer une fonctionnalité si les utilisateurs s'empressent de jeter les variables HTTP dans le scope global comme tu le fais ?
que veux tu dire parle scope global.
En programmation on parle de portée (scope) des variables. C'est grosso modo l'espace dans lequel elle sera accessible par son nom dans le programme. La portée globale, c'est par définition l'espace des variables accessibles par leur nom depuis partout dans le programme.
XSS détectée !
Je crois que tu n'as pas compris cette dernière remarque. Je t'invites à t'en inquiéter sérieusement. Ton script peut être la cible d'une attaque par injection SQL, voir de cross-site scripting (XSS). Mais c'est moins évident à faire dans ce cas. Il y a plein de site qui parlent de ça sur l'Intenet.
J'en vois... huit paires, celles qui englobent les isset.
Tu devrais faire une fonction qui teste la présence
de toutes ces clés dans le tableau $_POST. Et ne pas mettre des
parenthèses inutiles.
c'est a dire....
Si tu ne sais pas ce qu'est une fonction, je t'encourage à l'apprendre :
<http://fr2.php.net/manual/fr/language.functions.php>. Ça te fera gagner
du temps.
À quoi ça sert de supprimer une fonctionnalité si les utilisateurs
s'empressent de jeter les variables HTTP dans le scope global comme tu
le fais ?
que veux tu dire parle scope global.
En programmation on parle de portée (scope) des variables. C'est
grosso modo l'espace dans lequel elle sera accessible par son nom dans
le programme. La portée globale, c'est par définition l'espace des
variables accessibles par leur nom depuis partout dans le programme.
XSS détectée !
Je crois que tu n'as pas compris cette dernière remarque. Je t'invites
à t'en inquiéter sérieusement. Ton script peut être la cible d'une
attaque par injection SQL, voir de cross-site scripting (XSS). Mais
c'est moins évident à faire dans ce cas. Il y a plein de site qui
parlent de ça sur l'Intenet.
J'en vois... huit paires, celles qui englobent les isset.
Tu devrais faire une fonction qui teste la présence de toutes ces clés dans le tableau $_POST. Et ne pas mettre des parenthèses inutiles.
c'est a dire....
Si tu ne sais pas ce qu'est une fonction, je t'encourage à l'apprendre : <http://fr2.php.net/manual/fr/language.functions.php>. Ça te fera gagner du temps.
À quoi ça sert de supprimer une fonctionnalité si les utilisateurs s'empressent de jeter les variables HTTP dans le scope global comme tu le fais ?
que veux tu dire parle scope global.
En programmation on parle de portée (scope) des variables. C'est grosso modo l'espace dans lequel elle sera accessible par son nom dans le programme. La portée globale, c'est par définition l'espace des variables accessibles par leur nom depuis partout dans le programme.
XSS détectée !
Je crois que tu n'as pas compris cette dernière remarque. Je t'invites à t'en inquiéter sérieusement. Ton script peut être la cible d'une attaque par injection SQL, voir de cross-site scripting (XSS). Mais c'est moins évident à faire dans ce cas. Il y a plein de site qui parlent de ça sur l'Intenet.
J'en vois... huit paires, celles qui englobent les isset.
Tu devrais faire une fonction qui teste la présence de toutes ces clés dans le tableau $_POST. Et ne pas mettre des parenthèses inutiles.
c'est a dire....
Si tu ne sais pas ce qu'est une fonction, je t'encourage à l'apprendre : <http://fr2.php.net/manual/fr/language.functions.php>. Ça te fera gagner du temps.
je sais ce que c'est une fonction, mais c'est vrai que je ne les aient pas utilisé, je pensais finir le site le mettre en ligne et après amélioré mon code via les fonctions.
À quoi ça sert de supprimer une fonctionnalité si les utilisateurs s'empressent de jeter les variables HTTP dans le scope global comme tu le fais ?
que veux tu dire parle scope global.
En programmation on parle de portée (scope) des variables. C'est grosso modo l'espace dans lequel elle sera accessible par son nom dans le programme. La portée globale, c'est par définition l'espace des variables accessibles par leur nom depuis partout dans le programme.
en effet sous le nom global je connaissais, effectivement en passant en par les fonction je n'utiliserait que des variable locale.
est-ce que c'est judicieux de stocker tout ces fonction ou code php dans un fichier comme le css.
XSS détectée !
Je crois que tu n'as pas compris cette dernière remarque. Je t'invites à t'en inquiéter sérieusement. Ton script peut être la cible d'une attaque par injection SQL, voir de cross-site scripting (XSS). Mais c'est moins évident à faire dans ce cas. Il y a plein de site qui parlent de ça sur l'Intenet.
xss non j'ai pas compris, et jamais entendu parler
J'en vois... huit paires, celles qui englobent les isset.
Tu devrais faire une fonction qui teste la présence
de toutes ces clés dans le tableau $_POST. Et ne pas mettre des
parenthèses inutiles.
c'est a dire....
Si tu ne sais pas ce qu'est une fonction, je t'encourage à l'apprendre :
<http://fr2.php.net/manual/fr/language.functions.php>. Ça te fera gagner
du temps.
je sais ce que c'est une fonction, mais c'est vrai que je ne les aient pas
utilisé, je pensais finir le site le mettre en ligne et après amélioré mon
code via les fonctions.
À quoi ça sert de supprimer une fonctionnalité si les utilisateurs
s'empressent de jeter les variables HTTP dans le scope global comme tu
le fais ?
que veux tu dire parle scope global.
En programmation on parle de portée (scope) des variables. C'est
grosso modo l'espace dans lequel elle sera accessible par son nom dans
le programme. La portée globale, c'est par définition l'espace des
variables accessibles par leur nom depuis partout dans le programme.
en effet sous le nom global je connaissais, effectivement en passant en par
les fonction je n'utiliserait que des variable locale.
est-ce que c'est judicieux de stocker tout ces fonction ou code php dans un
fichier comme le css.
XSS détectée !
Je crois que tu n'as pas compris cette dernière remarque. Je t'invites
à t'en inquiéter sérieusement. Ton script peut être la cible d'une
attaque par injection SQL, voir de cross-site scripting (XSS). Mais
c'est moins évident à faire dans ce cas. Il y a plein de site qui
parlent de ça sur l'Intenet.
xss non j'ai pas compris, et jamais entendu parler
J'en vois... huit paires, celles qui englobent les isset.
Tu devrais faire une fonction qui teste la présence de toutes ces clés dans le tableau $_POST. Et ne pas mettre des parenthèses inutiles.
c'est a dire....
Si tu ne sais pas ce qu'est une fonction, je t'encourage à l'apprendre : <http://fr2.php.net/manual/fr/language.functions.php>. Ça te fera gagner du temps.
je sais ce que c'est une fonction, mais c'est vrai que je ne les aient pas utilisé, je pensais finir le site le mettre en ligne et après amélioré mon code via les fonctions.
À quoi ça sert de supprimer une fonctionnalité si les utilisateurs s'empressent de jeter les variables HTTP dans le scope global comme tu le fais ?
que veux tu dire parle scope global.
En programmation on parle de portée (scope) des variables. C'est grosso modo l'espace dans lequel elle sera accessible par son nom dans le programme. La portée globale, c'est par définition l'espace des variables accessibles par leur nom depuis partout dans le programme.
en effet sous le nom global je connaissais, effectivement en passant en par les fonction je n'utiliserait que des variable locale.
est-ce que c'est judicieux de stocker tout ces fonction ou code php dans un fichier comme le css.
XSS détectée !
Je crois que tu n'as pas compris cette dernière remarque. Je t'invites à t'en inquiéter sérieusement. Ton script peut être la cible d'une attaque par injection SQL, voir de cross-site scripting (XSS). Mais c'est moins évident à faire dans ce cas. Il y a plein de site qui parlent de ça sur l'Intenet.
xss non j'ai pas compris, et jamais entendu parler
Bruno Desthuilliers
Avant de savoir s'il est vide, il faut savoir s'il existe, et s'il est
justement est ce que si une variable esst vide est ce qu'elle existe dans la cas ou l'internaute validerait un post vide.
(snip)
désolé je me suis peux être mal exprimé.
j'ai eu le cas sur un script ou j'ai essayé de faire une isset suivi d'un empty imbriqué dans le premier if.
je me demandais si le formulaire est posté vide est ce que les variables testé par isset existe quand même,
C'est dans la spec HTTP, tout ça. Et la réponse est non. S'il n'y a aucune valeur positionnée pour un champ de formulaire, ce champ n'apparaitra pas dans la requête.
Au temps pour moi - au moins pour les inputs de type text et les select (pour les inputs type radio et - of course - submit, seul ce qui est utilisé apparaît dans la requête...)
Avant de savoir s'il est vide, il faut savoir s'il existe, et
s'il est
justement est ce que si une variable esst vide est ce qu'elle existe
dans
la cas ou l'internaute validerait un post vide.
(snip)
désolé je me suis peux être mal exprimé.
j'ai eu le cas sur un script ou j'ai essayé de faire une isset suivi d'un
empty imbriqué dans le premier if.
je me demandais si le formulaire est posté vide est ce que les variables
testé par isset existe quand même,
C'est dans la spec HTTP, tout ça. Et la réponse est non. S'il n'y a
aucune valeur positionnée pour un champ de formulaire, ce champ
n'apparaitra pas dans la requête.
Au temps pour moi - au moins pour les inputs de type text et les select
(pour les inputs type radio et - of course - submit, seul ce qui est
utilisé apparaît dans la requête...)
Avant de savoir s'il est vide, il faut savoir s'il existe, et s'il est
justement est ce que si une variable esst vide est ce qu'elle existe dans la cas ou l'internaute validerait un post vide.
(snip)
désolé je me suis peux être mal exprimé.
j'ai eu le cas sur un script ou j'ai essayé de faire une isset suivi d'un empty imbriqué dans le premier if.
je me demandais si le formulaire est posté vide est ce que les variables testé par isset existe quand même,
C'est dans la spec HTTP, tout ça. Et la réponse est non. S'il n'y a aucune valeur positionnée pour un champ de formulaire, ce champ n'apparaitra pas dans la requête.
Au temps pour moi - au moins pour les inputs de type text et les select (pour les inputs type radio et - of course - submit, seul ce qui est utilisé apparaît dans la requête...)
J'en vois... huit paires, celles qui englobent les isset.
Tu devrais faire une fonction qui teste la présence de toutes ces clés dans le tableau $_POST. Et ne pas mettre des parenthèses inutiles.
c'est a dire....
Si tu ne sais pas ce qu'est une fonction, je t'encourage à l'apprendre : <http://fr2.php.net/manual/fr/language.functions.php>. Ça te fera gagner du temps.
je sais ce que c'est une fonction, mais c'est vrai que je ne les aient pas utilisé, je pensais finir le site le mettre en ligne et après amélioré mon code via les fonctions.
Heu... Je sais bien que PHP est avant tout un (vrai) langage de script, donc pas un exemple en matière de bonnes pratiques, mais bon, comment dire... Les fonction, ce n'est pas de "l'amélioration", c'est le B.A.BA.
est-ce que c'est judicieux de stocker tout ces fonction ou code php dans un fichier comme le css.
Of course. En fait, les quelques scripts directement appelé dans une appli php ne devraient pas faire grand chose de plus que d'appeler ces fonctions.
XSS détectée !
Je crois que tu n'as pas compris cette dernière remarque. Je t'invites à t'en inquiéter sérieusement. Ton script peut être la cible d'une attaque par injection SQL, voir de cross-site scripting (XSS). Mais c'est moins évident à faire dans ce cas. Il y a plein de site qui parlent de ça sur l'Intenet.
xss non j'ai pas compris, et jamais entendu parler
Cross Site Scripting. Mais bon, dans ton cas (où tu construit ta requête SQL directement avec les données balancées par l'utilisateur, sans les valider (ce qui requiert plus que de vérifier qu'il y a quelque chose de posté...), tu risque surtout une injection SQL.
J'en vois... huit paires, celles qui englobent les isset.
Tu devrais faire une fonction qui teste la présence
de toutes ces clés dans le tableau $_POST. Et ne pas mettre des
parenthèses inutiles.
c'est a dire....
Si tu ne sais pas ce qu'est une fonction, je t'encourage à l'apprendre :
<http://fr2.php.net/manual/fr/language.functions.php>. Ça te fera gagner
du temps.
je sais ce que c'est une fonction, mais c'est vrai que je ne les aient pas
utilisé, je pensais finir le site le mettre en ligne et après amélioré mon
code via les fonctions.
Heu... Je sais bien que PHP est avant tout un (vrai) langage de script,
donc pas un exemple en matière de bonnes pratiques, mais bon, comment
dire... Les fonction, ce n'est pas de "l'amélioration", c'est le B.A.BA.
est-ce que c'est judicieux de stocker tout ces fonction ou code php dans un
fichier comme le css.
Of course. En fait, les quelques scripts directement appelé dans une
appli php ne devraient pas faire grand chose de plus que d'appeler ces
fonctions.
XSS détectée !
Je crois que tu n'as pas compris cette dernière remarque. Je t'invites
à t'en inquiéter sérieusement. Ton script peut être la cible d'une
attaque par injection SQL, voir de cross-site scripting (XSS). Mais
c'est moins évident à faire dans ce cas. Il y a plein de site qui
parlent de ça sur l'Intenet.
xss non j'ai pas compris, et jamais entendu parler
Cross Site Scripting. Mais bon, dans ton cas (où tu construit ta requête
SQL directement avec les données balancées par l'utilisateur, sans les
valider (ce qui requiert plus que de vérifier qu'il y a quelque chose de
posté...), tu risque surtout une injection SQL.
J'en vois... huit paires, celles qui englobent les isset.
Tu devrais faire une fonction qui teste la présence de toutes ces clés dans le tableau $_POST. Et ne pas mettre des parenthèses inutiles.
c'est a dire....
Si tu ne sais pas ce qu'est une fonction, je t'encourage à l'apprendre : <http://fr2.php.net/manual/fr/language.functions.php>. Ça te fera gagner du temps.
je sais ce que c'est une fonction, mais c'est vrai que je ne les aient pas utilisé, je pensais finir le site le mettre en ligne et après amélioré mon code via les fonctions.
Heu... Je sais bien que PHP est avant tout un (vrai) langage de script, donc pas un exemple en matière de bonnes pratiques, mais bon, comment dire... Les fonction, ce n'est pas de "l'amélioration", c'est le B.A.BA.
est-ce que c'est judicieux de stocker tout ces fonction ou code php dans un fichier comme le css.
Of course. En fait, les quelques scripts directement appelé dans une appli php ne devraient pas faire grand chose de plus que d'appeler ces fonctions.
XSS détectée !
Je crois que tu n'as pas compris cette dernière remarque. Je t'invites à t'en inquiéter sérieusement. Ton script peut être la cible d'une attaque par injection SQL, voir de cross-site scripting (XSS). Mais c'est moins évident à faire dans ce cas. Il y a plein de site qui parlent de ça sur l'Intenet.
xss non j'ai pas compris, et jamais entendu parler
Cross Site Scripting. Mais bon, dans ton cas (où tu construit ta requête SQL directement avec les données balancées par l'utilisateur, sans les valider (ce qui requiert plus que de vérifier qu'il y a quelque chose de posté...), tu risque surtout une injection SQL.
Mickael Wolff
je sais ce que c'est une fonction, mais c'est vrai que je ne les aient pas utilisé, je pensais finir le site le mettre en ligne et après amélioré mon code via les fonctions.
Fais relire ton source par un gars qui a de la bouteille avant de publier.
est-ce que c'est judicieux de stocker tout ces fonction ou code php dans un fichier comme le css.
Personnellement, je considère que le PHP doit polluer le moins possible le HTML, pour éviter les interminables recherches du bogue qui va mal ;)
xss non j'ai pas compris, et jamais entendu parler
C'est un ensemble de techniques permettant d'exploiter des manques de contrôles des données soumises. Vu que dans ton script tu ne contrôle rien, que tu ne protèges rien, on peut aisément détourner le fonctionnement du script. C'est une technique utilisée couramment pour envoyer massivement du Spam, ou utiliser le serveur comme zombie.
je sais ce que c'est une fonction, mais c'est vrai que je ne les aient pas
utilisé, je pensais finir le site le mettre en ligne et après amélioré mon
code via les fonctions.
Fais relire ton source par un gars qui a de la bouteille avant de publier.
est-ce que c'est judicieux de stocker tout ces fonction ou code php dans un
fichier comme le css.
Personnellement, je considère que le PHP doit polluer le moins
possible le HTML, pour éviter les interminables recherches du bogue qui
va mal ;)
xss non j'ai pas compris, et jamais entendu parler
C'est un ensemble de techniques permettant d'exploiter des manques de
contrôles des données soumises. Vu que dans ton script tu ne contrôle
rien, que tu ne protèges rien, on peut aisément détourner le
fonctionnement du script. C'est une technique utilisée couramment pour
envoyer massivement du Spam, ou utiliser le serveur comme zombie.
je sais ce que c'est une fonction, mais c'est vrai que je ne les aient pas utilisé, je pensais finir le site le mettre en ligne et après amélioré mon code via les fonctions.
Fais relire ton source par un gars qui a de la bouteille avant de publier.
est-ce que c'est judicieux de stocker tout ces fonction ou code php dans un fichier comme le css.
Personnellement, je considère que le PHP doit polluer le moins possible le HTML, pour éviter les interminables recherches du bogue qui va mal ;)
xss non j'ai pas compris, et jamais entendu parler
C'est un ensemble de techniques permettant d'exploiter des manques de contrôles des données soumises. Vu que dans ton script tu ne contrôle rien, que tu ne protèges rien, on peut aisément détourner le fonctionnement du script. C'est une technique utilisée couramment pour envoyer massivement du Spam, ou utiliser le serveur comme zombie.
