Skip to Content (Press Enter)
2012-08-01 17-33-40
Gerry
1120Views
6Comments
Solved
Transactional apps and the BACK button
Question
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?
0
0
05 Feb 2013
Copy Link
2013-03-14 12-00-25
Daniel Luz
Staff
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
See solution in context
BackButtonBrowserToPreparation.oml
3
0
31 Jul 2015
Copy Link
2022-11-12 11-28-30
Gonçalo Martins
Staff
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
0
0
05 Feb 2013
Copy Link
2012-08-01 17-33-40
Gerry
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"
 
0
0
20 Feb 2013
Copy Link
UserImage.jpg
22bc63ff-d68c-4193-824e-d79d2714f8b3
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.
0
0
20 Feb 2013
Copy Link
2020-08-05 08-52-58
Ruben Goncalves
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.
0
0
20 Feb 2013
Copy Link
2013-03-14 12-00-25
Daniel Luz
Staff
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
BackButtonBrowserToPreparation.oml
3
0
31 Jul 2015
Copy Link
2013-07-05 14-11-55
Cláudio Oliveira

Hi Daniel.

This works like a charm.

Thanks a lot.

1
0
07 Oct 2016
Copy Link
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.