Форум PHP

Как реализовать следующее, когда обработчик принял POST-данные, потом сформировался запрос и соответственно добавление в БД. При этом как исключить факт повторного с добавления в базу, если пользователь обновил страницу? Вариант с переадресацией не подходит

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

Например, оператор обрабатывает заявку пользователя, после обработки заявки ей присваивается идентификатор (primary key), по которой потом и оператор и пользователь может отслеживать состояние заявки. То есть после того как была нажата кнопка Обработать заявку - все сведения заносятся в БД.
Вдруг если пользователь нечаянно после этого обновит страницу, или интернет заключит, то произойдет дублирование, естественно, только идентификаторы заявки будут разные.

Я смею предложить что Вы сейчас предложите сделать что-то этого - Header("Location:order.php?id_order={номер заявки}");
Так?

От себя придумал такой вариант. На странице заполнения заявки (форма) генерируем случайное число. Это число записываем в куки с именем, например, rand, и также передаем его в скрытом поле POST-запросом с именем тоже rand.
Далее на странице обрабочике сверяем это значение из кук с со значением из post, если верно, производим операцию, затем чистим куки.
Этот вариант работает, но может я не прав.

Вариант с переадресацией (если Вы о header/Location) именно для этого и служит.
И если он Вам не подходит, в Ваших интересах описать, почему именно.

К слову сказать, явной попытка повторной отправки данных (повторное нажатие submit до исполнения предыдущего запроса) гасится другим способом -- например так, как указал Valick

Он мне первый в голову пришел. Но не совсем он мне подходит. Почему - я написал выше.

Вы не написали, почему Вам не[совсем] подходит header/location

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

Это как: взял гвоздь - неминуемо придется стукнуть молотком.

И кирпичом и микроскопом тоже можно стукнуть.
Но эффект не тот.

PS. Возможно, адекватной формой запроса будет выбрана INSERT ... ON DUPLICATE KEY UPDATE

>C моей точки зрения, не подходить (причем при любом POST-запросе) он не может, так как является естественным продолжением алгоритма обработки POST.

Где написано что он является продолжением алгоритма обработки POST?????????????????????????

Если использовать Header(), то потом можно будет спровоцировать результат обработки заявки, которая была совершена давно, подставив идентификатор любой заявки.
Можно, конечно, придумать защиту, но это потребует более усилий.

>>C моей точки зрения, не подходить (причем при любом POST-запросе) он не может, так как является естественным продолжением алгоритма обработки POST.
>
>Где написано что он является продолжением алгоритма обработки
POST?????????????????????????

Вы только что процитировали. У меня написано.
Защищиать очевидные ( для знакомого с протоколом http и методикой взаимодействия браузер-сервер) вещи достаточно странно. Но аргументы можно найти, если надо.



>Если использовать Header(), то потом можно будет спровоцировать результат обработки заявки, которая была совершена давно, подставив идентификатор любой заявки.
>Можно, конечно, придумать защиту, ...

Не защиту, а корректный алгоритм обработки данных.
>...но это потребует более усилий.

Последний агрумент выносит мозг напрочь.

В этой жизни требует усилий всё.
Если Вы не хотите что-то делать - не беритесь!

>>>C моей точки зрения, не подходить (причем при любом POST-запросе) он не может, так как является естественным продолжением алгоритма обработки POST.
>>
>>Где написано что он является продолжением алгоритма обработки
>POST?????????????????????????
>
>Вы только что процитировали. У меня написано.
>Защищиать очевидные ( для знакомого с протоколом http и методикой взаимодействия браузер-сервер) вещи достаточно странно. Но аргументы можно найти, если надо.

Пожалуйста, найдите.. очень хочется их от Вас услышать.
>
>>Если использовать Header(), то потом можно будет спровоцировать результат обработки заявки, которая была совершена давно, подставив идентификатор любой заявки.
>>Можно, конечно, придумать защиту, ...

>Не защиту, а корректный алгоритм обработки данных.
>>...но это потребует более усилий.
>
>Последний агрумент выносит мозг напрочь.
>
>В этой жизни требует усилий всё.
>Если Вы не хотите что-то делать - не беритесь!

Согласен. Но усилия должны быть оправданы. А решение должно быть продуманным. Валик предложил хорошее решение. Я примерно так и поступил.

Trianon, переадресация, идеально подходит, например, после добавления новой темы на форуме. А здесь нет, никак, не должно. Я достаточно ясно аргументировал почему - выше.

ничего Вы не аргументировали, переход может быть на главную страницу, или на страницу spasibo.php на которой написано "Спасибо", а с нее через несколько секунд куда угодно....
но это все мелочи по сравнению с тем что Header("Location:order.php?id_order={номер заявки}"); у Вас не работает должным образом
что мешает набрать в адресной строке order.php?id_order={номер заявки} и сделать все то что сделает "страшный редирект"?
__
по идее Header("Location:order.php?id_order={номер заявки}"); должен показывать статус заявки в любой момент времени
принята к рассмотрению | принята | отклонена

>ничего Вы не аргументировали, переход может быть на главную страницу, или на страницу spasibo.php на которой написано "Спасибо", а с нее через несколько секунд куда угодно....
Видел такое на ipb форуме (если не ошибаюсь в названии). Согласен, использование переадресации там к месту, но опять же сделали через .... потому что с задержкой.

>но это все мелочи по сравнению с тем что Header("Location:order.php?id_order={номер заявки}"); у Вас не работает должным образом
>что мешает набрать в адресной строке order.php?id_order={номер заявки} и сделать все то что сделает "страшный редирект"?

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

какой в болото оператор?
если не ошибаюсь речь шла о пользователе оставляющем заявку, как только нажали кнопку отправить, скрипт обрабатывает полученные данные (по мне так он вообще должен сразу записывает её в базу и делать пометку что заявка еще не рассмотрена) и перенаправляет куда угодно этого самого пользователя.
А оператор уже должен обработав заявку присвоить ей статус принято или отклонено
и допустим через день или неделю удалять все заявки со статусом отклонено.

Я подразумевал под словом пользователь оператора)))) Пользователи (это клиенты) звонят по телефону, а операторы уже вносят сведения)))

и вы не оставляете шанса пользователю самому заполнить форму? за что Вы так с клиентами?))
Вам просто нужно разобраться в логике... просто опишите словами по порядку что нужно сделать, а потом принимайтесь кодить "в темную голову"

Я тут непричем)))) И пользователю Ваш метод не поможет) Это типичный Сервис Деск интернет-провайдера. У пользователя пропадает инет, он звонит в службу поддержки и по телефону сообщает что инет не работает. оператор принимает сведения и забивает заявку. заявка помещается в очередь и ждет своего череда. Затем оператор в техотделе у себя в интерфейсе видит необработанные заявки, сообщает инженеру сведения, тот разбирается, в этот момент заявка имеет статус - в обработке. когда все налажено - заявка в корзину (образно).

Убедили, буду вариант с переадресацией использовать))))

А оператор-приемщик и оператор-технолог сидят друг от друга за многие сотни километров? При чем тут интренет тогда, что-то не понятно.

непричем

Ну а тогда какие проблемы, зачем POST и header вообще нужны? Чай для разных кабинетов лучше писать приложение под ОС, поддерживающее доступ в локальной сети.
Ниче не понятно.

Использую тонкий клиент. Есть вероятность, что на другом конце города откроется еще один офис. фирма у нас маленькая, растет по-тихоньку.

Ну даже в этом случае, не будет же оператор-приемщик из одного офиса, давать задание оператору-технологу из дугого офиса. А база общая (для клиентов), так кто мешает ее обновлять данными из разных офисов?

Что значит обновлять?

Офис А обрабатывает жалобы Пупкина, Иванова, Николаева....
Офис Б обрабатывает жалобы Сидорова, Петрова....
Технолог офиса А отправляет на сервер С уже готовые решения по этим жалобам, с подтверждением получения....
Технолог офиса Б отправляет на сервер С уже готовые решения по этим жалобам, с подтверждением получения....
Сервер С получает эти данные и, или добавляет их, или обновляет, все зависит от того, как орагнизована база данных.

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

За секунду навряд-ли ваша фирма примет решение по жалобе, да и жалоб может рассматриваться в одно и тоже время много, а значит и обновление на сервере можно производить не одиночное, а групповое. Header, признак в сессии, или иная защита, это уж не так и грузно получится при этом, чего вы боитесь.

Ясно.Спасибо, буду думать.


p.s. Честно говоря мне не очень нравится оконные приложения. Технологи используют у себя только линукс, поэтому если придется делать как говорите вы, то придется использовать кроссплатформеные решения. По времени затрано. Ну это уже другой вопрос

Ну не знаю, я лично не представляю корпаративное решение на гольном веб. База клиентская содержит приватные данные, и сеть используется для обмена данными между офисами. А вот для клиентов выставляется только часть из этих данных, публичная, и через, например, личный кабинет, частная, на сервере. Изменение данных в клиентской базе отражаются в базе на сервере.

PS. У вас ведь в любом случае будет головной офис, он и должен содержать клиентскую базу данных, а значит и обновление серверной базы, это задача одного офиса.

>Согласен. Но усилия должны быть оправданы. А решение должно быть продуманным. Валик предложил хорошее решение. Я примерно так и поступил.

Так и в Valick'овом решении header|location никуда не исчез :) как я вижу.

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

Я имел ввиду это

это достаточно скользкая дорожка :)
пилите перенаправляйте, Шура, перенаправляйте... :)

Это - само собой.

Хотя на мой взгляд, здесь лучше применить генерируемый в момент создания кода формы жетон, код которого записывать в скрытый параметр формы и в БД - на место предполагаемой записи.
И запись менять по этому жетону, фиксируя последнюю версию контента.