Discussion :

[moreall]

Bonjour à tous,
J'ai une page de traitement php qui reçoit des variables en POST d'une plate-forme de paiement. Cette page ne doit pas faire d'actions trop longues et je dois donc transmettre certaines variables à une autre page pour d'autres actions.
Pour cela je ne peut pas utiliser de session, par contre avec la fonction header() et les variables passées en GET (genre Location = 'test.php?var1="' . $_POST['var1] .'"') ça marche.
Y a -t-il une contre-indication à fonctionner de la sorte et est ce que ça pose des problèmes de sécurité?
Quels sont les autres moyens de faire la même chose (et les bonnes pratiques)?

merci d’avance

[sabotage]

Il faut seulement prendre en compte que l'utilisateur peut envoyer n'importe quelles données lui même vers ta page de traitement.
Ensuite une URL n'est pas censé accueillir trop de données et il existe des limitations à 256 caractères.

La session est une meilleure methode.

[moreall]

Normalement l'utilisateur n'a pas accès à cette page qui ne doit pas être affichée (C'est d'ailleurs la raison pour laquelle je ne peux pas utiliser de session).
C'est une page qui sert juste à exécuter un script à partir de variables en POST venant d'une plateforme de paiement...

[sabotage]

Je ne comprends pas ton problème par rapport à la session.

Pour la sécurité, rien n’empêche ton utilisateur d’accéder à la page de traitement.
D'ailleurs puisque tu fais une redirection, il doit voir son url et les paramètres.

[moreall]

Je vais essayer de mieux m'expliquer:

Sur une page d'achat d'un site marchand l'utilisateur clique sur un bouton "Payer" qui envoie des données en POST vers une plateforme extérieure de gestion de paiement.
La plateforme gère le paiement puis renvoie le résultat du paiement en POST vers une page php de traitement du site marchand. Cette page n'est donc pas appelée par l'utilisateur, elle sert juste à valider le paiement.
Pour effectuer des traitements php supplémentaires la page de traitement du site marchand transmet à une nouvelle page (contenant un script php) certaines variables précédemment renvoyées par la plateforme de paiement (cette nouvelle page n'est donc pas appelée par l'utilisateur).
Pour passer ces variables à cette nouvelle page je ne pense pas pouvoir utiliser de session, comment cette nouvelle page pourrait-elle récupérer l'id de la session?
J'ai pensé à faire une redirection avec la fonction header() et les variables en GET, j'ai testé et ça fonctionne mais je me demande si il n'y a pas une meilleure façon de faire (à part insérer les données dans une BDD pour qu'elles puissent être récupérer ailleurs).

Voilà, j'espère que c'est plus clair.

[sabotage]

Je suppose donc que ton utilisateur est connecté sur ton site avec utilisation d'une session PHP.
Pense bien que si tu ne fais rien contre, l'utilisateur peut aussi bien accéder à la page de retour qu'a la page de traitement.
Concernant la session PHP, quand l'utilisateur revient du paiement, sa session est toujours active et donc sur la page de traitement aussi.

Pour finir, pourquoi le traitement n'est pas fait sur la page de retour directement ?

[moreall]

Le traitement n'est pas fait sur la page de retour pour éviter au maximum d'y intégrer des tâches consommatrices de temps (genre génération de facture ou envoi de mail).

En ce qui concerne l'utilisateur il est effectivement connecté avec utilisation d'une session PHP mais comment récupérer l'id de sa session sur la page de retour puisque cette page est appelée par la plateforme de paiement et non pas par l'utilisateur?

[ABCIWEB]

Si tu fais un session_start() sur ta page de retour, tu devrais pouvoir récupérer les variables de session utilisateur même si cette page est appelée de l'extérieur.

[sabotage]

pour éviter au maximum d'y intégrer des tâches consommatrices de temps

Je ne vois pas bien la différence entre faire tout le traitement sur une page et faire une redirection vers une page qui fait le traitement.

[moreall]

Le temps du traitement sur la page de retour (qui n'est pas vue par l'utilisateur) influe directement sur le délai de l’affichage de la page de résumé du paiement (celle que voit l'utilisateur sur la plateforme de paiement).
Plus le traitement de la notification est long, plus l’affichage est retardé, ça peut aller jusqu'au timeout.

@ABCIWEB
En supposant qu'il y ait plusieurs sessions ouvertes en même temps sur mon serveur, je ne comprends pas comment la page de retour, appelée de l'extérieur et non pas par l'utilisateur, peut choisir la bonne session.

[sabotage]

La page de retour n'est pas appelée depuis l’extérieur : c'est toujours le client web qui est le demandeur.

[moreall]

Justement non, c'est un traitement automatique issu de la plateforme de paiement, transparent pour l'utilisateur...

[sabotage]

Ce n'est pas parce que l'utilisateur ne voit rien que ce n'est pas son client qui est demandeur de la ressource.
Après ce que tu me dis est possible mais en général ce n'est pas comme ça que fonctionne une plateforme de paiement : en général le site marchand transmet les informations à la plateforme, celle-ci valide le paiement et redirige le client vers le site marchand.

[moreall]

Dans le cas de cette plateforme, quand elle valide (ou non) le paiement il y a un appel automatique vers ce qu'ils appellent l'url serveur du site marchand (renseignée par le site marchand et destinée à faire les traitements liés au paiement).
Le client est ensuite redirigé vers le site marchand (si c'est cette option qui est choisie, le client pouvant aussi rester sur la page de résumé du paiement avec un bouton de retour).