Passage de structures de données Perl sous forme de chaînes GET sérialisées à un programme CGI Perl

Question

Je souhaite transmettre une structure de données Perl sérialisée en tant que variable GET à une application CGI. J'ai essayé Data :: Serializer comme première option. Malheureusement, la chaîne sérialisée est trop longue pour mon confort, en plus de contenir des options jointes par '^' (un caret).

Existe-t-il un moyen de créer des chaînes codées courtes à partir de structures de données Perl afin de les transmettre en toute sécurité en tant que variables GET à une application CGI Perl?

J'apprécierais également de savoir que cela (chaînes sérialisées et codées) est un mauvais moyen de passer des structures de données complexes à des applications Web et des suggestions sur la façon dont je pourrais accomplir cela

Answer 1

Si vous devez envoyer à vos utilisateurs des URL contenant quelques points de données clés et que vous souhaitez vous assurer qu'elles ne pourront pas être falsifiées, vous pouvez le faire avec un Digest (tel que Digest :: SHA) et un secret partagé. Cela vous permet de placer les données dans vos messages sans avoir à conserver une base de données locale pour tout suivre. Mon exemple n'inclut pas d'élément de temps, mais ce serait assez facile à ajouter si vous le souhaitez.

use Digest::SHA qw(sha1_base64);
my $base_url = 'http://example.com/thing.cgi';

my $email = 'guy@somewhere.com';
my $msg_id = '123411';

my $secret = 'mysecret';
my $data = join(":", $email, $msg_id, $secret);
my $digest = sha1_base64($data);

my $url = $base_url . '?email=' . $email . '&msg_id=' . $msg_id' . '&sign=' . $digest;

Envoyez-le ensuite.

Dans votre " thing.cgi " script, il vous suffit d'extraire les paramètres et de voir si le résumé soumis dans le script correspond à celui que vous régénérez localement (à l'aide de $ email et $ msg_id, et bien sûr de votre $ secret). Si elles ne correspondent pas, ne les autorisez pas. Si c'est le cas, vous avez une demande légitimement autorisée.

Note de bas de page:
J'ai écrit le " raw " méthodes dans Data :: Serializer pour rendre la traduction entre les sérialiseurs beaucoup plus facile et qui aide en fait à passer d’une langue à l’autre. Il s’agit bien entendu d’une discussion séparée, car vous ne devriez jamais utiliser de sérialiseur pour échanger des données sur un formulaire Web.

Answer 2

L’un des inconvénients de l’approche - en utilisant un sérialiseur spécifique à Perl, est que si vous souhaitez communiquer entre le client et le serveur en utilisant autre chose que perl, cela demandera probablement plus de travail que quelque chose comme JSON ou même XML serait. Les limitations de taille des requêtes GET que vous avez déjà rencontrées, mais cela pose problème pour tout schéma de codage.

Cela posera probablement plus de problèmes au prochain utilisateur de la maintenance de ce code qu’à vous-même. Je me trouve actuellement dans une situation où un développeur qui travaillait sur un grand système avant moi a décidé de stocker plusieurs bits de données importants sous forme d'objets perl Storable. Ce n’est pas une décision horrible en soi, mais il est plus difficile que prévu d’accéder aux données avec des outils qui ne sont pas écrits en Perl.

Answer 3

La transmission de chaînes codées sérialisées est un mauvais moyen de transmettre des structures de données complexes à des applications Web.

Si vous essayez de passer d'un état à l'autre, vous pouvez utiliser le sessions du serveur. qui ne nécessiterait que vous transmettiez une clé de session.

Si vous devez envoyer un lien par courrier électronique à une personne, vous pouvez toujours créer une session côté serveur avec un délai d'expiration raisonnable (vous devrez également décider si une authentification supplémentaire est nécessaire), puis envoyer l'identifiant de session dans le lien. . Vous pouvez / devez expirer la session immédiatement une fois que l'action demandée est entreprise.