Передача base64_encoded сериализованных данных между отправками формы

Question

Я создаю серию форм на основе мастера для ввода пользовательских данных. Одним из требований для этого мастера является то, что сценарий (PHP) не может сохранять входные данные в базу данных (MySQL), пока пользователь не нажмет кнопку «Сохранить», поэтому я должен создать механизм для переноса пользовательских данных в одной форме в другую когда пользователь нажимает кнопки «Предыдущий» или «Следующий». Я изучил использование различных методов, включая файлы cookie, сеансы, временные файлы и т. Д., Но решил встроить данные сериализации base64_encoded в скрытое поле, которое существует во всех формах серии. Значение в этом поле будет декодировано при отправке формы и перекодировано для помещения в следующую форму после вставки других значений из текущей формы.

Вот пример того, как выглядит скрытое поле:

<input type="hidden" name="wizard:presave" value="YTo2OntzOjU6InRpdGxlIjtzOjEwOiJRdWVzdGlvbiAyIjtzOjQ6InRleHQiO3M6MTk6IlllcyBpdCdzIGEgcXVlc3Rpb24iO3M6NDoidHlwZSI7czo2OiJjaG9pY2UiO3M6NzoiY2hvaWNlcyI7YTowOnt9czo1OiJwb2ludCI7aToxO3M6Mjoib3AiO3M6MTM6ImVkaXRfZXhlcmNpc2UiO30=" />

Итак, вопросы:

1. Считается ли это хорошей / плохой практикой?

2. Есть ли ограничение длины скрытых полей в HTMLform?

3. Каковы возможные проблемы безопасности?

4. А есть ли лучшие альтернативы? (с пояснениями, желательно без использования javascript)

Заранее спасибо!

Answer 1

Считается ли это хорошей / плохой практикой?

Зависит от цели. До сих пор я видел только такие конструкции как хэш URL-адреса на стороне клиента, чтобы запомнить состояние выборок в больших приложениях на основе ajax (чтобы они были добавлены в закладки), а затем часто также Gzip, чтобы сделать его короче. В вашем конкретном случае я бы сказал: используйте сеанс HTTP и передавайте только идентификатор, основанный на запросе (также называемый токен ), в скрытое поле, чтобы вы могли получить связанную информацию из сеанса.

Есть ли ограничение длины скрытых полей в HTML-форме?

В GET полная строка запроса (все имена параметров и значения и разделители вместе) обычно ограничена 2048 символами, но вы можете лучше придерживаться строгого ограничения в 256 символов. В POST это зависит от конфигурации сервера. Часто это по умолчанию около 2 ГБ.

Каковы возможные проблемы безопасности?

Ну, это, очевидно, возможность декодирования.

И есть ли лучшие альтернативы? (с пояснениями, желательно без использования javascript)

Вы можете сжать его, чтобы сделать его короче и менее заметным. Или, как уже было сказано, используйте сеанс в сочетании с идентификатором на основе запроса.

Answer 2

1. Я никогда не видел такого метода передачи параметров в своей карьере, поэтому я не могу сказать, хорошо это или плохо. Это конечно не "стандарт". Стандартные методы будут либо передавать переданный метод (без кодирования / обычно) с использованием скрытых входных данных, либо сохранять в сеансе. Я думаю, что вы, возможно, делаете работу для себя, поэтому в этом смысле она будет склоняться к «не идеальному».

2. Пока вы используете POST для своих форм, не существует определенного предела для размеров данных, о которых я знаю в спецификациях HTTP. Старые серверы могут иметь практические ограничения, но если вы не делаете что-то экстремальное, например, загрузку медиа-файлов, они не должны беспокоиться.

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

4. Сессии будут работать намного лучше здесь. Данные, которые пользователь отправляет, не должны проходить длительный процесс кодирования. Кроме того, вам нужно будет подтвердить это только один раз. После того, как он был отправлен и проверен, вы можете просто сохранить его на сервере в $ _SESSION и оставить его в покое, пока не будет нажата последняя кнопка. В противном случае вам придется беспокоиться о его повторном выводе, повторном получении и повторной проверке на каждом шаге. Злонамеренный пользователь может отправить один набор данных, проверить его и повторно вывести как закодированные данные, но затем обработать следующую отправку формы путем декодирования, изменения данных и перекодирования.

Я бы настоятельно рекомендовал вам пересмотреть сеансы, поскольку это упрощает все ваши операции с данными в сценарии с однократным выполнением.

Answer 3

тск тск:)

1. Считается ли это хорошей / плохой практикой? субъективно - плохая практика .. вы используете не тот молот для работы.

2. Есть ли ограничение длины скрытых полей в HTMLform? - Не уверен, есть ли предел.

3. Каковы возможные проблемы безопасности? - Возможно, довольно много, но вы можете очистить данные, полученные для каждого запроса. Кроме того, данные довольно легко декодируются и могут быть легко изменены на стороне клиента (я вижу, что это своего рода json, который вы используете :))

4. А есть ли лучшие альтернативы? (с объяснениями, желательно без использования JavaScript) - Используйте правильный инструмент .. сессий возможно?

И да ... Скорее всего, вы столкнетесь с проблемами производительности и масштабируемости (если у вас будет значительная нагрузка на пользователя), когда весь код очистки, синтаксического анализа, форматирования и безопасности выполняется для каждого запроса.

Answer 4

Ну, вы можете сохранить в сеансе либо сериализацию, либо просто сохранить его таким, каким он является для каждого шага. Когда пользователь нажимает кнопку Сохранить, вы получаете и проверяете данные всех шагов сеанса.