Передача структур данных Perl в виде сериализованных строк GET в программу Perl CGI

Question

Я хочу передать сериализованную структуру данных Perl в качестве переменной GET в приложение CGI.Я пытался Данные::Сериализатор как мой первый вариант.К сожалению, для моего удобства сериализованная строка слишком длинная и содержит параметры, соединенные знаком '^' (каретка).

Есть ли способ создавать короткие закодированные строки из структур данных Perl, чтобы я мог безопасно передавать их как переменные GET в приложение Perl CGI?

Я также был бы признателен, если бы мне сказали, что это (сериализованные, закодированные строки) — плохой способ передать сложные структуры данных в веб-приложения, и предложения о том, как я мог бы это сделать.

Answer 1

Если вам нужно отправить пользователям URL-адреса, содержащие несколько ключевых точек данных, и вы хотите убедиться, что их невозможно подделать, вы можете сделать это с помощью дайджеста (например, из Digest::SHA) и общего секрета.Это позволяет вам помещать данные в свои сообщения без необходимости хранить локальную базу данных для отслеживания всего этого.Мой пример не включает элемент времени, но при желании его будет достаточно легко добавить.

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;

Тогда пошлите его вместе.

В вашем сценарии «thing.cgi» вам просто нужно извлечь параметры и посмотреть, соответствует ли дайджест, представленный в сценарии, тому, который вы локально регенерируете (используя $email и $msg_id и, конечно же, ваш $secret).Если они не совпадают, не авторизуйте их, если они совпадают, то у вас есть законно авторизованный запрос.

Сноска:
Я написал «необработанные» методы в Data::Serializer, чтобы значительно упростить перевод между сериализаторами, и это действительно помогает при переходе между языками (до определенного момента).Но это, конечно, отдельная дискуссия, поскольку вам действительно не следует использовать сериализатор для обмена данными в веб-форме.

Answer 2

Один из недостатков подхода & # 8212; используя специфичный для Perl сериализатор, то есть & # 8212; в том, что если вы когда-нибудь захотите общаться между клиентом и сервером, используя что-то отличное от Perl, это, вероятно, будет более трудоемким, чем что-то вроде JSON или даже XML. Ограничения размера запросов GET, к которым вы уже выполнялись, но это проблематично для любой схемы кодирования.

Скорее всего, это проблема для следующего парня, который поддерживает этот код, чем для вас. У меня возникла ситуация, когда разработчик, который работал над большой системой до того, как я это сделал, решил сохранить несколько важных фрагментов данных в виде хранимых объектов perl. Само по себе это не ужасное решение, но оно затрудняет доступ к данным с помощью инструментов, написанных не на Perl.

Answer 3

Передача последовательных закодированных строк - плохой способ передачи сложных структур данных в веб-приложения.

Если вы пытаетесь передать состояние со страницы на страницу, вы можете использовать сеансы на стороне сервера. , что потребует только передачи ключа сеанса.

Если вам нужно отправить кому-то ссылку по электронной почте, вы все равно можете создать сеанс на стороне сервера с разумным сроком действия (вам также необходимо решить, нужна ли дополнительная аутентификация), а затем отправить идентификатор сеанса в ссылке , Вы можете / должны прервать сеанс сразу же после выполнения запрошенного действия.