envoie variable GET pb de &

[vince.bbob]

Bonjour,

J'ai un formulaire comportant un input de type text. Mon formulaire est envoyer en GET. Le client entre un texte de son choix. Mon probleme est si il entre le '&', je ne recupere pas la fin, pour le php c'est une autre variable. Comment faire ??

Je veux et je doit rester en GET

Par exemple :

<?php
page.php?texte=bonjour&salut
?>

Le "salut" disparait

Merci pour vos reponses

Modifié 23 Mai 2008 par vince.bbob

[captain_torche]

Essaye en remplaçant "&" par "&"

[vince.bbob]

Je veux bien remplacer le & par &amp mais quel est cette fonction ?

[ASC]

Evite les type guest... utilise plutot POST pour tes méthodes. c'est moins dangereux.

ensuite tu peux faire un traitement sur ton/tes champ(s)

<?php

function rem_accent( $src )

{

$gen = array(" ", "&");//tu peux y mettre autant d'occurences que tu veux.

$rem = array("_", "-");//tu dois avoir ici le meme nombre de remplacement.

$src = str_replace($gen, $rem, $src);

return $src;

}

function format_champ( $src )

{

$src = strip_tags( $src );

$src = addslashes( $src );

//Pour les text area:

$src = nl2br( $src );

$src = rem_accent( $src );

return $src;

}

if( isset( $_GET['monchamp1'] ) ){ $monchamp1 = format_champ( $_POST['monchamp1'] ); }

if( isset( $_POST['monchamp1'] ) ){ $monchamp1 = format_champ( $_POST['monchamp1'] ); }

//ensuite tu traite ton résultat.

?>

ASC.

[captain_torche]

ASC : En quoi une variable passée en GET est plus sensible qu'une passée en POST ?

Ce sont toutes deux des variables envoyées par l'utilisateur, donc il faut les contrôler de la même manière.

[Ifmy]

page.php?texte="bonjour&salut"

M'enfin bon ça rox pas du poney ce GET

(le type guest ? )

sinon & c'est juste la valeur html de &

ça ne changera rien

[vince.bbob]

Que me propose tu, Ifmy pour corriger ce probleme ??

Je te rassure je n'envoie pas qu'une seule variable en GET et je l'envoie en Ajax. Mais cela fonctionne c'est pas ca mon souci.

Mon souci c'est le &, le + etc ....

[Kioob]

Le seul problème ce sont les "injections XSS" : par exemple tu ajoutes sur ton site une image "cachée" avec une adresse du genre &quot;http://gmail.com/addRewrite.php?type=all&email=pirate_AT_tipiac.fr".

S'il n'y a pas de vérification et qu'un gars avec une session valide "gmail" passe sur ton site, le traitement sera lancé...

Bref, de manière générale tout ce qui est "action" devrait être déclenché via POST, même si c'est parfois contraignant.

Par contre pour le problème en question : les navigateurs encodent déjà correctement les données... Donc soit le formulaire est (mal) soumis en JS, soit il y a une étape qui m'échappe coté PHP.

S'il y a vraiment une étape coté PHP, c'est à coup de rawurlencode() qu'il faut protéger tes variables.

Modifié 23 Mai 2008 par Kioob

[Ifmy]

Et bien comme écrit plus haut si vous ne voulez pas vous casser la tête en revoyant le fonctionnement du site, encadrez simplement le texte dans des quotes (")

cela devrait fonctionner.

page.php?texte="bonjour&salut"

[gomi]

Salut,

je pense que sincèrement ton problème n'est pas tant dans le contenu a envoyé mais plutôt dans la récupération des variable envoyé par le formulaire.

- il faut utiliser un POST qui lui est plus sécurisé que le GET

- Pour récupérer les variables je te donne un exemple:

Page de formulaire :

<form name="form1" method="post" action="pagetraitement.php">

<p>

<input name="Info1" type="text" id="Info1">

</p>

<p>

<textarea name="info2" id="info2"></textarea>

</p>

<p>

<input type="submit" name="Submit" value="Envoyer">

</p>

</form>

Page de traitement (pagetraitement.php)

Il faut faire ceci:

<?php

//recuperation de l'information une infos1

$infos1 = $_POST['infos1'];

//recuperation de l'information une infos2

$infos2 = $_POST['infos2'];

//affichage des elements

echo $infos1;

echo $infos2;

?>

Avec cette méthode tu retrouveras sans problème des informations avec plus de sécurité.

J'espere t'avoir aider.

[captain_torche]

- il faut utiliser un POST qui lui est plus sécurisé que le GET

Je repose ma question : en quoi la variable POST est-elle plus sécurisée que GET ?

Elles sont toutes deux issues des entrées de l'internaute et doivent par conséquent être correctement testées avant utilisation.

[Ifmy]

Je repose ma question : en quoi la variable POST est-elle plus sécurisée que GET ?

Elles sont toutes deux issues des entrées de l'internaute et doivent par conséquent être correctement testées avant utilisation.

Allez j'essaye

La seul chose que je vois et que le POST a pour avantage d'empêcher les injections type SQL directement dans l'URL

Mis à part elles ne sont pas forcement issues d'une entrée directe de l'internante mais cela n'empêche pas de les tester.

EDIT : Il faudrait un chan irc au hub lol

Modifié 23 Mai 2008 par Ifmy

[captain_torche]

Il est très facile d'envoyer ce que l'on veut avec une en-tête POST (J'utilise pour ça une extension firefox : urlparams, par exemple).

C'est pour ça qu'il ne faut pas à mon sens considérer qu'elle est plus sécurisée que GET.

Sinon, il y a un chat sur le Hub, déjà

[ASC]

ASC : En quoi une variable passée en GET est plus sensible qu'une passée en POST ?

Ce sont toutes deux des variables envoyées par l'utilisateur, donc il faut les contrôler de la même manière.

Les gets sont visibles en url... Il suffirait qu'il passe un mot de passe par exemple par get pour une conexion et imaginons qu'il pense pas utiliser md5()... bas n'importe quelle personne qui se connecte tout ceux qui passent derrière voient tout... et c'est qu'un exemple parmis tant d'autres...

Allez j'essaye

La seul chose que je vois et que le POST a pour avantage d'empêcher les injections type SQL directement dans l'URL

Mis à part elles ne sont pas forcement issues d'une entrée directe de l'internante mais cela n'empêche pas de les tester.

EDIT : Il faudrait un chan irc au hub lol

Oh un chan irc ca serait vraiment mortel ! J'y passerai mes journées lol

et +1 pour l'explication de ifmy.

Modifié 23 Mai 2008 par ASC

[steph29]

dans un formulaire en get le & est automatiquement remplacé par le navigateur quand c'est une valeur....

le pb peut arriver si c'est toi qui construit l'url... (pour une redirection, un script ajax, etc..)

ici c'est pour le script ajax, tu dois donc remplacer le & par un & avant de l'envoyer...

[Ifmy]

Il y a vraiment des jours ou j'ai l'impression d'être dans un monde parallèle ...

je vais donc récapépèter doucement avec des mots simples pour ceux qui... hum bref

page.php?texte="bonjour&salut"

• Le ? dit : ce qui est après moi doit être passé en GET
  
• Le = dit : ce qui est avant moi est "un nom de variable" et ce qui est après moi, la valeur de celle-ci
  
• Le & ou & dit : ce qui est après moi est une nouvelle variable
  

Donc, si je sais de quoi je parle (sinon je m'abstiens) j'en déduit très logiquement que salut est une variable. pour les septiques :

<?php
if (isset($_GET["salut"])) echo "Hello world";
?>

La solution est donc d'encadrer bonjour&salut par des quotes. Ainsi texte:String prend la valeur bonjour&salut.

Ensuite :

Pourquoi & ? tout simplement par ce qu'en xhtml, l'utilisation du & rend le code non valide. (voir pourquoi sur w3c.org) Il faut donc encoder ce caractère ainsi : &

remplacez & par & dans vos urls et rechargez la page, vous verrez que cela ne change strictement rien.

[Kioob]

Mon post étant passé à la trappe à priori : htmlspecialchars() n'y changera rien. C'est un paramètre d'URL ici, même saisi "à la main" dans la barre d'adresse ça ne passera pas. Il faut utiliser rawurlencode() pour encoder correctement ce &. Et pour les & qui sont valides (ceux qui séparent les vrais arguments de la requête) c'est effectivement htmlspecialchars() (et donc & qui doit être utilisé).

Et comme l'a rappelé steph29, une erreur d'encodage de ce type vient certainement d'une erreur de construction coté script (JS à priori), étant donné que dans le cas d'un formulaire classique (même en GET) le navigateur fait déjà très bien son boulot.