PHP, MySQL: как сохранить и извлечь правильные данные при работе с нумерацией страниц

0

У меня есть форма (состоящая из 25 + полей), а значения для этих полей варьируются от крошечного значения до конкатенированной строки. Это похоже на инструмент поиска. Теперь, когда пользователь заполняет форму и отправляет информацию, он получает все соответствующие данные, соответствующие критериям в форме. Я показываю 15 записей за раз для пользователя. Я выполнил разбивку на страницы, чтобы пользователь мог видеть и другие записи.

ОСНОВНАЯ ПРОБЛЕМА:

Часть, пока пользователи не отправят информацию и не вернут 1-й набор данных, хороши. Проблема возникает, когда пользователь пытается перейти на вторую страницу (или любую страницу по своему выбору) с помощью разбивки на страницы. Пользователь может перейти на другие страницы, но запрос, который необходим для правильного выполнения для выведения результатов из БД, не запускается. Обратите внимание, что вначале это была операция POST, которая была выполнена в форме, а разбиение на страницы выполняло операцию GET. Поэтому я теряю значения формы, которые пользователь вводит, и я хочу сохранить эти значения и запросить БД с этими значениями.

Я пытаюсь избежать отправки значений поля формы через GET, потому что я боюсь, что данные могут превышать максимально допустимое значение в URL (& поскольку оно менее безопасно, чем операция POST). На странице результатов могут быть выполнены другие операции, которые могут привести к потере значений формы, если я попытаюсь использовать операцию POST (например, запрос на обновление). Сеансы на самом деле не работают, так как пользователь может выбрать одну и ту же форму на разных вкладках с разными входами для сравнения результатов, и это может привести к замене данных более старого запроса на данные из нового запроса. Я не думал о куки, поскольку пользователь, возможно, решил заблокировать его. Практически все варианты, похоже, исчерпаны.

Итак, что я могу сделать, чтобы сохранить значения формы, запустить правильный запрос и вернуть соответствующие значения независимо от того, сколько раз одна и та же форма может обрабатываться одним и тем же пользователем в разных вкладках/окнах браузера без использования сеансов (учитывая ограничения на передачу данных через GET и, возможно, их потерю в POST-операциях) и возможность выполнять другие действия на странице?

Спасибо заранее.

Теги:
forms
pagination

3 ответа

2
Лучший ответ

Во-первых, GET не менее безопасен, чем POST. Обеим не нужно доверять (более привлекательно изменять строку URL, но ни в коем случае не сложнее)...

У вас есть несколько вариантов:

Один из них - сохранить глобальный "магазин" результатов поиска. Вы можете использовать таблицу db с id, data, где данные представляют собой сериализованный массив переменных. Затем, когда кто-то отправляет запрос, проверьте, находятся ли данные в таблице. Если это так, используйте этот идентификатор. Если нет, то сериализуйте данные и вставьте их (и получите идентификатор). Затем переадресовываем страницу, например: results.php?id=4. Таким образом, они могут совместно использовать ссылку, но она остается разумно защищенной от подделки (они не могут изменять параметры поиска). Недостатком здесь является то, что таблица может расти ОГРОМНЫМ.

Другим было бы кодирование данных base64 на base64 и передача их через параметр get (base64_encode(serialize($data));). Я постараюсь держаться подальше от этого, если вы заинтересованы в подделке или длине URL.

Другим решением было бы перехватить следующий щелчок ссылки в JS и использовать его для отправки POST обратно на ваш сервер из скрытых переменных.

EDIT: Удалено решение для сеанса. Понял, что это не сработает для вашей проблемы.

Поделиться
  • 0
    Спасибо за ответ. Хранение в БД звучит хорошо. Мне просто нужно следить за ними. Я еще немного подумаю над тем, как это можно сделать с помощью того же подхода. Благодарю.
  • 0
    Как индекс столбца данных (который содержит сериализованный массив переменных) повлияет на результаты нашего поиска? Индекс по этому, безусловно, будет быстрее, но, учитывая объем данных, что вы предлагаете?
Показать ещё 2 комментария
0

Возможным подходом было бы сохранение всего запроса, который вы использовали для поиска в своей базе данных, в таблице, называемой search_queries. Эта таблица должна содержать по существу два столбца, хэш и запрос, используемые для этого элемента поиска.

Когда пользователь отправляет форму поиска, его запрос оценивается и вставляется в эту таблицу, и он перенаправляется на страницу с помощью search_hash. Каждый раз, когда он переходит на другую страницу, его хэш вытаскивается из базы данных, и результаты пересматриваются соответственно - с надлежащим LIMIT, конечно.

Убедитесь, что вы столкнулись с этой таблицей (для этого вам может понадобиться отметка времени для каждого элемента поиска)

Другая жизнеспособная реализация этого подхода заключалась бы в том, чтобы сохранить запрос в переменной SESSION и использовать его для вашей цели запроса. Для разбивки на страницы вы бы /search?page=1, а ваш _SESSION['query'] был бы, например, "SELECT * FROM Topics WHERE title LIKE '%test%'". Вы бы добавили "LIMIT "+($page*$perpage)+", $perpage"

Однако последний подход не сможет обнаружить многооконные окна, которые этот пользователь имеет с сайтом. Вы можете использовать массив в _SESSION ['queries'], и пользователь должен отправить /search?id=0&page=1, где id будет представлять запрос запроса массива, который вы запрашиваете в этом окне.

Поделиться
  • 0
    Спасибо за ответ. Сессии не очень полезны в моем случае. Я думал об использовании хранения в БД, как предложил ircmaxell, и я вижу, что вы предложили подобный подход немного по-другому. Спасибо за то же самое.
0

Я пытаюсь избежать отправки формы значения поля через GET, потому что я боюсь что данные могут превышать максимальные допустимое значение в URL

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

Но нет причин, по которым вы не можете хранить несколько запросов в одном сеансе, например. $_SESSION [ 'запросы'] [1234]. Тогда ваши ссылки на страницы выглядят так: query = 1234 & page = 3

Считайте, однако, что пользователям может быть полезно иметь доступ к URL-адресам своих результатов поиска. например, если Google использовал исключительно POST, я не мог отправить вам ссылку на http://google.com/search?q=somequery

(& поскольку он менее безопасен, чем операция POST)

Не совсем.

Поделиться
  • 0
    Спасибо за ответ. Сессии менее полезны в моем случае. Не могли бы вы рассказать мне, что вы упомянули об обмене URL-адресами? Я вроде как потерял тебя из-за этого.
  • 0
    Скажем, ваш пользователь, Боб, хочет поделиться страницей результатов, которые он просматривает в вашем приложении, со своей коллегой Салли. Чтобы это работало хорошо, URL в адресной строке должен содержать достаточно информации для восстановления всего запроса.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню