Have browsers broken post-redirect-get? best practice now?

[graeme]

The Django  docs (and a lot else) recommend redirecting after successfully processing a post request (if it changes data). i.e. post, the save stuff to the database, then redirect.

Current browsers seem to allow this. I have tried Chromium 28 and 24 on Linux, I user return redirect(...) after the post, and I can still use the back button.

Is it my configuration, or is it usual? What is the best practice if this is broken?

In some cases I think tracking where the user is (in the session, or using the state of a particular object such as an order model), and redirecting any request for an earlier page in a sequence may be the way to go. Or is this a solved problem that I am too far behind the curve to know about?

[antialiasis]

You should still be able to use the back button; it just shouldn't try to post the data again if you do so. Are you getting a prompt about resending post data, or are you just talking about being able to use the back button at all? If the latter, that's exactly what should happen. Breaking the user's back button is bad.

[graeme]

I disagree that breaking the back button is always bad. For example suppose you have a series of forms (i.e. a "wizard"):

Page 1) fill in form. On POST creates a new Model() and saves it to the database

2) do stuff to the object (e.g. add inlines, whatever).

3) ....whatever comes next

At stop two, user clicks back. They then post the form again, and get another object. On the other hand the page in step 2 can provide a back button on the page that takes the user back to edit what they entered on page 1. Which is more useful? I would say the latter - and users may not then understand that the browser back button and page back button do different things.

[David Durham]

I think when they hit the browsers back button, the form will have the
data they entered previously. When they submit it, since it was
already submitted previously, you could just make it an edit action,
or do whatever is appropriate given that they are submitting the same
form again. I think the functionality of the browser's back button is
universal and accepted and shouldn't be broken or reinvented.

-Dave

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/cf0dd1f1-b004-4595-800f-1190ca9f4171%40googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.

[Darren Spruell]

On Thu, Oct 3, 2013 at 6:15 AM, graeme <graeme....@gmail.com> wrote:
> I disagree that breaking the back button is always bad. For example suppose
> you have a series of forms (i.e. a "wizard"):
>
> Page 1) fill in form. On POST creates a new Model() and saves it to the
> database
> 2) do stuff to the object (e.g. add inlines, whatever).
> 3) ....whatever comes next
>
> At stop two, user clicks back. They then post the form again, and get
> another object. On the other hand the page in step 2 can provide a back
> button on the page that takes the user back to edit what they entered on
> page 1. Which is more useful? I would say the latter - and users may not
> then understand that the browser back button and page back button do
> different things.

Django supports this form wizard behavior in a sane way through Form Wizards:

https://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/

In the case of form wizards, each step through the series of forms in
the wizard occurs from the same URL, and the API provides users a way
to traverse individual forms (steps) in the wizard in a controlled
way. If the client uses the browser back button, it drops them back
from the URL the form wizard is served from, not to a previous step in
the form.

DS

> On Tuesday, October 1, 2013 8:33:41 PM UTC+5:30, antialiasis wrote:
>>
>> You should still be able to use the back button; it just shouldn't try to
>> post the data again if you do so. Are you getting a prompt about resending
>> post data, or are you just talking about being able to use the back button
>> at all? If the latter, that's exactly what should happen. Breaking the
>> user's back button is bad.
>>
>> On Tuesday, October 1, 2013 12:41:20 PM UTC, graeme wrote:
>>>
>>> The Django docs (and a lot else) recommend redirecting after
>>> successfully processing a post request (if it changes data). i.e. post, the
>>> save stuff to the database, then redirect.
>>>
>>> Current browsers seem to allow this. I have tried Chromium 28 and 24 on
>>> Linux, I user return redirect(...) after the post, and I can still use the
>>> back button.
>>>
>>> Is it my configuration, or is it usual? What is the best practice if this
>>> is broken?
>>>
>>> In some cases I think tracking where the user is (in the session, or
>>> using the state of a particular object such as an order model), and
>>> redirecting any request for an earlier page in a sequence may be the way to
>>> go. Or is this a solved problem that I am too far behind the curve to know
>>> about?
>

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/cf0dd1f1-b004-4595-800f-1190ca9f4171%40googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.

--
Darren Spruell
phatb...@gmail.com

[graeme]

On Friday, October 4, 2013 3:51:30 AM UTC+5:30, david.durham.jr wrote:

I think when they hit the browsers back button, the form will have the
data they entered previously.  When they submit it, since it was
already submitted previously, you could just make it an edit action,

That is what I mostly do - but if the step they go back to is stop 1 in my list (i.e. create an object with initial data)

how then its unclear what they expect.

There are also some steps that are irrevocable - e.g. going back to change an order after paying should not be allowed.

[graeme]

On Friday, October 4, 2013 12:00:47 PM UTC+5:30, dspruell wrote:

On Thu, Oct 3, 2013 at 6:15 AM, graeme <graeme....@gmail.com> wrote:
> I disagree that breaking the back button is always bad. For example suppose
> you have a series of forms (i.e. a "wizard"):
>
> Page 1) fill in form. On POST creates a new Model() and saves it to the
> database
> 2) do stuff to the object (e.g. add inlines, whatever).
> 3) ....whatever comes next
>
> At stop two, user clicks back. They then post the form again, and get
> another object. On the other hand the page in step 2 can provide a back
> button on the page that takes the user back to edit what they entered on
> page 1. Which is more useful? I would say the latter - and users may not
> then understand that the browser back button and page back button do
> different things.

Django supports this form wizard behavior in a sane way through Form Wizards:

Its the right way to do it in general, agreed - although in some cases it seems to be

more work than doing it from scratch.

 

https://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/

In the case of form wizards, each step through the series of forms in
the wizard occurs from the same URL, and the API provides users a way
to traverse individual forms (steps) in the wizard in a controlled
way. If the client uses the browser back button, it drops them back
from the URL the form wizard is served from, not to a previous step in
the form.

It does not, in itself, answer my question, because clicking the back button after

posting a page takes you back to the previous (state of the) page, even if you remain

 on the same URL.

I think the answer is avoid breaking the back button, unless its essential.