SQL Commands retriggered when browser pages back in history

[Former user]

Originally reported on Google Code with ID 104

What steps will reproduce the problem?
1. Insert Into table from SQL tab
2. check table
3. go back in history, insert is retriggered when the page is reloaded

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
1.9.1, On Linux using a webkit browser (dwb)

Please provide any additional information below.

I don't know if there is any way to change this behavior, from now on I'll avoid browsing
back, but it seems like a pretty easy way to accidentally insert extra data into a
table. Thanks for phpliteadmin!

Reported by aplannan2 on 2012-05-11 14:58:55

[Christopher Kramer]

``` Well, this is the case for most web applications. That's why normally, the browser will display a warning that POST data will be resent which might result in taking an action twice. The same happens with most web applications like forums etc. If you just ignore the browser's warning, some action will be taken again.

But there is a way around this. We could give the form some random key, store it in a session, and remove it from the session once it is sent the first time. If then it is sent again, we could display some message "Do you really want to do this another time?".

This is possible and might avoid some accidental actions. But I do not consider this a must-have, therefore I will set Priority to "low" so we can fix this once no important bugs are left.

In fact I'd love to see browsers explaining this scenario better to users. Most users just do not understand what it means to go back to a site and resend POST data. Firefox's new "Document expired" message does not help much here.

So maybe I can teach you here: If you sent a form and want to go back without sending the form again, go back _two_ steps. In firefox, click on the back button longer to open the dropdown and select the second item from the top. In most other browsers, some little arrow allows you to open this list.

By the way, I will try to go back after submitting this post to see whether Google code bugtracker has the same behaviour. If you see this post twice, it has ;-) ```

Reported by `crazy4chrissi` on 2012-06-01 23:01:15 - Labels added: Priority-Low - Labels removed: Priority-Medium

[Christopher Kramer]

``` Alright, Google Code bugtracker does not have this issue. And it uses another approach to avoid it: The page you POST the form to uses a 301 permanent redirect the browser automatically opens via GET. In the browsers history, the POST-page is therefore replaced with the redirected GET page. So no matter how you browse your history, you will never resend the form. I consider this the best approach. We might implement this one day, but not for the moment I guess.

By the way, I think this considers about any POST form in phpLiteAdmin, not only SQL Query, but also normal inserts and such forms. ```

Reported by `crazy4chrissi` on 2012-06-01 23:11:19

[Christopher Kramer]

Reported by crazy4chrissi on 2014-04-15 09:53:35 - Status changed: Accepted

[phpLiteAdmin]

This is solved now with commit c17738a18419. confirmed table actions now don't return the $completed/error message directly but redirect and the redirect target displays the message and the normal content. This solves issue #104. But it needs some more work - e.g. something needs to be done regarding the debug output inside table actions which currently break the redirect.

[phpLiteAdmin]

Changeset: f8a5d7ee60bd Summary: Dropdown Database list now uses get methods instead of post and therefore does not break the back-button anymore (issue #104). Also recent changes broke the dropdown because a table parameter was automatically added.

[phpLiteAdmin]

Changeset: 088eb030becf

Summary: Login and logout don't break the back-button anymore. logout now uses GET instead of POST. Login uses $params->redirect. This is related to issue #104.