Discussion :

[Julio_del_pueblo]

Bonjour tout le monde, je débute et je voudrais savoir comment rediriger vers une page en y incluant des variables en POST ?

D'avance merci.

[Invité]

Y'a une methode de porc pour faire suivre des valeur d'une page a l'autre :
Creer un formulaire cache (hidden) que tu rempli avec les valeur envoyee.

Tu peut aussi mettre les valeur dans un $_SESSION,

[cerede2000]

Oui la methode la plus adapté c'est d'utiliser les sessions... Parce que un formulaire de champs hidden c'est vraiment n'importe quoi

[viviboss]

Y'a une methode de porc pour faire suivre des valeur d'une page a l'autre :
Creer un formulaire cache (hidden) que tu rempli avec les valeur envoyee.

Tu peut aussi mettre les valeur dans un $_SESSION,

C'est pas forcément une méthode de porc, cela dépend si tu as déjà un formulaire ou non. Il n'y a pas d'excusivité d'utilisation d'une méthode ou d'une autre, $_SESSION, $_GET et $_POST ont tous leur utilité, et ce même pour passer de page en page !!!! (perso, j'utilise $_GET pour les variables classiques, et les $_SESSION pour les données un peu plus chaudes, comme les validations login, ou autres variables éphémères)

[cerede2000]

Eu passer des variables en faisant un formulaire avec que des champs hidden c'est quand meme n'importe quoi...
Apres c'est sur que toutes les methodes on leurs utilités et moi aussi je les utilises toutes...

[viviboss]

Bon, c'est sur....1 point, le form avec que du hidden c pas terr ible...

[Julio_del_pueblo]

Merci pour vos réponses, mais j'ai encore des doutes ... les variables par $_SESSION c'est bien c'est propre mais comment l'associer à une page unique ? Je m'explique: comment faire quand l'utilisateur a deux fois la même page d'ouverte dans le même navigateur mais avec des données différentes ... comment faire pour ne pas mélanger les variables lors de la redirection ?

Autre question:
Je veux passer d'une action A d'un controleur 1 vers une action B d'un controleur 2 ... avec en plus des paramêtres ...

Je fais un $this->_redirect('/2/B'); avec des variables en session ??
Est ce conceptuellement parlant une bonne méthode ?

Julio.

[viviboss]

Les session, comme post ou get, sont des superglobal.... Et sont accessible via des tableaux correspondant : si tu fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
//page 1
<?php
session_start();
$_SESSION['nom']="viviboss";
 
header("Location: page2.php".SID);
?>

Là, tu initialise une variable session. Elle sera disponible tant que la session sera ouverte, ou non détruite, ou par défaut dans les 30 minutes d'inactivités.
(note le SID, qui permet de transmettre l'ID de session créé automatiquement à session_start(). Ceci est valable si dans ton php.ini transsid est à off dans la section "session")

Dans ta page 2 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
<?php
session_start();
echo $_SESSION['nom'];
//renverra le nom mis en session
//Pour détruire la variable,
unset($_SESSION['nom']);

ote en ore une fois le session_start() en haut de page : quand tu utilises des sessions, il faut toujours commencer tes documents php par ca : si une session est ouverte sur le serveur et qu'elle correspond à l'ID transmit (soit par la constante SID soit par transsid), alors la session continue, sinon une nouvelle session démarre....

Donc en gros, tu peu gérer ce que tu veux, t'as pas tellement de contraintes.... (à noter que la commande rafréchir des navigateurs vident les vareiables de Session, car elles dépendent du contexte....)

[Invité]

Pour rediriger les variables POST de page en page, il faut utiliser le code HTTP 307, sinon elles sont perdues.
Tous les navigateurs, sauf IE et Safari, vont demander une revalidation de le soumission des paramètres entre les 2 requêtes, c'est un principe de sécurité, discuté ici
La trame HTTP est alors de la forme :

POST /testRedirect.php HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 3
a=b

// header("Location:RedirectTo.php",true,307);
HTTP/1.x 307 Temporary Redirect
Location: RedirectTo.php

// ici, demande de renvoie de la part des navigateurs puis:
POST /RedirectTo.php HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 3
a=b

HTTP/1.x 200 OK

[viviboss]

...Donc le 307 est une redirection temporaire des données.... (Je dis ca à chaud, pas encore fait de recherches sur le sujet;... )

Mais je comprend pas vraiment : les variables POST sont de toute les façons transmises, dès lors qu'on a un formulaire avec ou sans hidden... (Bon, il faut valider...), donc je vois pas tellement l'intérêts ....

Tu aurais un peu plus d'infos ? Merci !!!!!

PS : qu'est ce que t'y connais au php ?! (toujours rêvé de dire ca à quelqu'un de balèse en PHP, en plus venant de l'AFUP..... ) lol

Edit : je suis fatigué le matin, j'ai pas vu ton liens....

[viviboss]

Cependant, alors que Opera et Firefox respectent la RFC, il n'en est pas de même pour IE, même dans sa dernière version ( IE7 ), qui semble tout simplement ignorer ce fait, et permettre donc au piège de se refermer. Ainsi, une redirection POST d'un domaine A vers un domaine B, se fera sans aucun avertissement sous IE, ce qui n'est pas très rassurant.

Bref, à bas IE et Crosoft (ils en font vraiment qu'à leur tête.... ), et vive les SESSION qui ne retransmettent pas vers un domaine externe...

[Invité]

Pour information, il est fortement déconseillé de transmettre le SID dans l'URL, sous peine de vol de session ( j'écris un article là dessus, qui va sortir d'ici peu de temps ).
Préférez les cookies.

Et pour répondre à une autre question, si un utilisateur a 2 onglets ouverts pointant sur la même page, alors les 2 pages seront liées par son identifiant de session, et donc la session sera partagée entre les 2 onglets ( même domaine, donc cookie de session trabsmit à chaque requête par le navigateur ).
En réalité : les sessions servent à ca hein, avant de s'en servir pour tout et pour rien, il faut se souvenir de la definition même d'une session, et de son but, afin de ne pas s'etonner de certains comportements, et de les utiliser à bon escient

[viviboss]

Pour la transmission de SID : moi je l'utilise tout le temp, et il n'aparait jamais dans l'URL.... Il se trouve que j'ai le transsid à on, ca veut dire qu'il a la priorité ? (Mes URL finissant par SID, ne voient finalement jamais le SID à la fin....)

Pour les Cookies, le problème est tjs le même : les accepter, ne pas les accepter.... Tel est la question... Du moins de l'internaute moyen (tout le monde devrait savoir que les Cookies ne sont pas malveillant.... )

[Invité]

Si tu vois pas le SID, c'est que c'est transmit par cookie.
Le cookie a la priorité. De plus, énormément d'utilisateurs acceptent les cookies de nos jours.
Tous les experts en sécurité le disent en conférence ( Ilia Alshanetsky - Chris Shiflet - Damien Seguy - Marco Tabini... ), forcez l'utilisation des cookies pour transmettre le sid, et désactivez pleinement le url.transid
PHPSecInfo le signale de même

[Julio_del_pueblo]

Merci à tous les deux, vos informations me sont très précieuses.

Julio.

[viviboss]

Si tu vois pas le SID, c'est que c'est transmit par cookie.
Le cookie a la priorité. De plus, énormément d'utilisateurs acceptent les cookies de nos jours.
Tous les experts en sécurité le disent en conférence ( Ilia Alshanetsky - Chris Shiflet - Damien Seguy - Marco Tabini... ), forcez l'utilisation des cookies pour transmettre le sid, et désactivez pleinement le url.transid
PHPSecInfo le signale de même

OK, au moins c'est clair (cette période un peu obscurantiste de mon PHP.ini prend fin.... ) Cela dit, je ne créé jamais de cookies, donc il le fait automatiquement ? Je sais pas si dans "PHP5 avancé" c'est décrit précisément (sans faire de lèche, c'est bien mon livre de chevet...si, si !!!! ) Bref, je me renseignerait plus en avant, en fait pour le SID j'avais surtout suivi les explication du manuel php pour l'utilisation des sessions (cette partie du manuel se fait peut être un peu vieillotte...)

Julio, merci pour ton POST, j'en ai aussi beaucoup profité

[Invité]

Bien sûr qu'il le fait tout seul.
PHP est un langage de script serveur, il pilote donc le serveur.

C'est pour ca qu'à chaque appel de session_start(), PHP flushe les en-tête HTTP en envoyant un en-tête setCookie: pour envoyer le cookie, et que donc " on ne doit rien écrire avant un session_start()" , voila l'expliquation ;-)

[viviboss]

Bien sûr qu'il le fait tout seul.
PHP est un langage de script serveur, il pilote donc le serveur.

C'est pour ca qu'à chaque appel de session_start(), PHP flushe les en-tête HTTP en envoyant un en-tête setCookie: pour envoyer le cookie, et que donc " on ne doit rien écrire avant un session_start()" , voila l'expliquation ;-)

Le pire, c'est que je le savais ..... Holala, quel gros newbie je fais....

Merci !!!

[Yogui]

Salut

Pour répondre à la question initiale, nous avons un article à ce sujet (sans ZF mais il suffit d'adapter) : http://g-rossolini.developpez.com/tu...aires-et-php5/

[ClemLamb]

Bref, à bas IE et Crosoft (ils en font vraiment qu'à leur tête.... ), et vive les SESSION qui ne retransmettent pas vers un domaine externe...

Moi je ne vois pas vraiment de problème, ou de faille à proprement parler puisque l'exemple founi dans ce lien, ne démontre pas un problème lié à l'utilisation de redirection + envoi de données en POST, mais un problème de XSS du site en question.

Pour ma part, je ne vois pas de différence avec une redirection en GET, si ce n'est que c'est transparent pour le client.