Transactional apps and the BACK button

Transactional apps and the BACK button

  
I've noticed that bad things can happen when a user hits the BACK button to go back to a page containing a transaction and resubmits it. I believe that since it's cached, the preparation does not run and the data is stale. How are you handling things like this?
Hi Gerry,

In that case you can use for example a validation on the Preparation to check if you already done the change you need. You can also use a flag in your Entity to control this, ie if you save once you update that flag, use the Commit action and then you can check its value.
This allow you to control the Back button problem and also if you have several browser tabs open in the same page..

Kind Regards,
Gonçalo Martins
Gonçalo Martins wrote:
Hi Gerry,

In that case you can use for example a validation on the Preparation to check if you already done the change you need. You can also use a flag in your Entity to control this, ie if you save once you update that flag, use the Commit action and then you can check its value.
This allow you to control the Back button problem and also if you have several browser tabs open in the same page..

Kind Regards,
Gonçalo Martins
When a user hits the BACK button to go back to a page that has a transaction, the Preparation does not run again. The page is in an odd state and it's possible for the user to redo that transaction with stale data.

One thing we are trying is to disable the caching of these pages. When you do this, the Preparation does run again and you have the opportunity refresh the pages' data.

We added 3 AddHeader actions in the Menu's Preparation (so that it's on every page) containing the following:

Action: Addheader
Name: "Pragma"
Value: "no-cache"

Action: AddHeader
Name: "Expires"
Value: "-1"

Action: AddHeader
Name: "Cache-Control"
Value: "no-store, no-cache, must-revalidate"
 
Hi, i haven't tried this, but here's what i would do:
1 - Capture the event "Back Button Click" ( i don't know if it's possible [JavaScript perhaps?]), then assign an X value to a session variable, whenever the "Back Button Click" event occurs.
2 - In the crucial pages have validations/verifications focus in that session variable, and if it was X value then you could do a counter action to stop the user from resubmiting.

On another approach, you could also try to disable the "Back Button" on the pages.

Regards,
Miguel Vieira.
Hi Miguel,

The approachs that you suggest, unfortunatelly not always work.
I've been with the same question same time ago, and after a lot of search and tests with scripts, the best thing that I could do, that worked was to add those http header, just like Gerry suggested.
Solution
Hi guys,

Sorry to revive an old thread, but recently we ran into a similar requirement so I'll share our approach in hopes it benefits someone :)

The situation we were trying to solve was going back to a stale page with outdated form data and repeating actions, which cause errors. For example, resubmitting a request that has in the meantime moved on in the process.
Another example is when the user logs out, then hits back and still gets a page, although he should be redirected to the login page.

First of all, I agree with the "don't mess with the Back button" approach. It's a standard button, and disabling it or making it do different things should be avoided.
So we didn't disable it.

What we did was this:
- Add a hidden input to the page - initialize it to some value (for example 'no') - so when the page is rendered by the server it always has a 'no'
- Add a bit of Javascript to the page ready event to:
  - Check that value - if it's not what you'd expect from the server (in our case, <> 'no'), force refresh the page (see below)
  - If it is still set to what you'd expect from the server, change it (in our case to 'yes') and do nothing else

This way, when you hit Back, the page ready event is triggered but the contents of the input is 'yes' because this page isn't fresh from the server (our JS set this value to 'yes' when it was previously rendered) so our JS now forces a refresh of the page, which should solve all our problems.
If the user logged out, the refresh will throw a security exception and send him to the login page, as expected.
If he submitted the form already, the refresh will update the form with the current data (and if the state is not editable, appropriate errors are shown/user is redirected).

Hope this is of some use. I attached an espace that contains an example implementation of this.

Cheers,
Daniel
Solution

Hi Daniel.

This works like a charm.

Thanks a lot.