Transactions

L'application sert à gérer des documents fournis par les utilisateurs, à partir de documents squelette fourni par l'administrateur, selon un calendrier de rendu, et avec une gestion de qui fourni quel document quand, qui note quel document quand. Donc, il est fondamentale d'avoir la possibilité

• d'enregistrer un document squelette,
• d'en récuperer un,
• de rendre un document renseigné,
• de consulter et noter un document renseigné.

Ces opérations sont courantes, et pourtant, les réussir avec html/http et une application php en toute sécurité nécessite étude et réflexion. Comme souvent, la recherche de la solution s'est faite brique par brique.

La première brique était “comment recevoir et stocker un fichier dans une table d'une base de données.” Comment recevoir le fichier est couvert par html/http, formulaire et POST, puis des fonctions php pour traiter la matière réceptionnée.

La deuxième brique était “comment fournir un document” à un utilisateur. Le problème était double, voir triple. Premièrement, si le fichier est stocké dans une table d'une base de données, il faut assurer le transfert d'une copie de son contenu formatté comme un fichier. Second, le faire avec une opération POST.

Il existe un problème avec la méthode POST de HTML : rafraichir la page renvoye les valeurs de nouveau, déclenchant la même opération de traitement.

Une solution proposée est d'utiliser un jeton qu'on invalide après le premier traitement. Ainsi on commence avec

<?php
  $token = /* a randomly generated string */;
  $_SESSION['_token'] = $token;
?>
<input type="hidden" name="_token" value="<?php echo $token; ?>" />

et lors du traitement, on teste si $_POST['_token']==$token. Si oui, on traite et puis on change $token pour éviter que ce soit vrai si la post est répétée.

L'inconvénient est qu'ainsi le formulaire ne peut servir que pour une seule opération, il me semble. L'utilisateur qui veut télécharger un deuxième ficher tout de suite derrière le premier (sans rafraichir la page) verra sa demande refusée car son token ne correspondra plus. Il faudra alors regénérer le formulaire avec un nouveau jeton en correspondence, et comment faire cela simplement et proprement, sans heurter les sensibilités de l'utilisateur?

Dans l'appli CLE, le token est attribué pour la session (lors de login?). L'invalider pendant la session n'est donc pas une option, il faudrait un autre jeton géré par le controlleur.

le passage de valeurs du controlleur à la view se fait par

      $this->registry->template->userArray = $userArray;

      $this->registry->template->show('View_CreatePromo');

Ainsi, on pourrait rajouter

$this->registry->template->postCount = 0;

La question est abordée sur stackoverflow. On y évoque le système de jetons, mais une des réponses me semble particulièrement sensée:

Using tokens in conjunction with the POST/REDIRECT/GET design pattern seems to be the best available solution.

• Setting a single-use token would prevent the user from hitting the back button and trying to submit the form again.
• Redirecting the user and using a view to display the input allows them to hit refresh if they please.

L'information Wikipedia qu'il cite concernant le patron redirect after post existe aussi en français (mais en encore plus court).

header(“Location: new-page.php”);

The HTTP response status code 303 See Other is the correct manner in which to redirect web applications to a new URI, particularly after an HTTP POST has been performed. This response indicates that the correct response can be found under a different URI and should be retrieved using a GET method. The specified URI is not a substitute reference for the original resource. This status code should be used with the location header. 303 See Other is one way of responding to a request for a URI that identifies a real-world object according to Semantic Web practice (the other being the use of hash URIs)[1].

Client request:

GET / HTTP/1.1
Host: www.example.com

Server response:

HTTP/1.1 303 See Other
Location: http://example.org/

[edit]