0

Does a real solution exist to the problem of being able to go back and forth with browser buttons in a ASP.NET MVC 5 application?

Use case:

Page A: Displays some data in a table and 2 buttons "Delete, Confirm". First one deletes data, second one goes to page B Page B: Displays some other data based on the previous, and a "Continue with next step" button.

Pages actions are in GET. Buttons are in POST (with a form)

User clicks "Delete", data gets deleted, then hits back browser button and Asp net mvc shows page A again. You still see data in the table and clicking "Delete" leads to an error. You can also click forward and go to the page B, which will still shows data even if the real data was deleted.

What happens as of now (Latest Chrome, Edge, didn't try other browsers): Seems browser automatically caches these pages. Hitting back and forth retrieves the cached version with data still in it (all cached). No action is called on the controller, you can go back and forth all you want and not a single call to the controller is made. So you don't have any real control over it.

Tests done: Back button doesn't cause postback to a controller action in MVC

Does nothing. Still retrieves the cached page.

How do we control web page caching, across all browsers?

Same as above.

https://forums.asp.net/t/1957310.aspx?Capture+Browser+Back+Button+and+execute+controller+action+

Same as above.

How to disable the browser back button in my mvc from only my login page?

Does not disable back button.

And so on with the various flavours of the previous links. I even tried mixing them togheter, putting all the headers and NoCache and such attributes and javascript togheter.

Nothing.

Solution found: Put the control on buttons, which calls an ajax post and are forced to do a real call everytime.

Does a solution for this exists?

Liquid Core
  • 1
  • 6
  • 27
  • 52

4 Answers4

1

Trying to override native web browser function is bad idea. You will struggle through multiple browsers behaviors and their further updates. The best solution is to reload your data on page entry through ex. ajax call using javascript.

Adlorem
  • 1,457
  • 1
  • 11
  • 10
0

Typically you would do a post and then redirect which solves the back button issue. More details here: https://damienbod.com/2018/06/15/asp-net-core-mvc-form-requests-and-the-browser-back-button/

jjxtra
  • 20,415
  • 16
  • 100
  • 140
0

Place this script on the page you want to prevent the user getting back to: <script> this.history.forward(-1); </script>

NMeneses
  • 152
  • 6
  • 20
-1

After deleting the record you can try this.

Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(DateTime.Now);
Response.Cache.SetNoServerCaching();
Response.Cache.SetNoStore();
Rafaqat Ali
  • 676
  • 7
  • 26
Arpit Srivastava
  • 9
  • 2
  • Tired all of those but doesn't work. It sill serves the cached page and doesn't call an action in code. – Liquid Core Jan 02 '20 at 11:05
  • 1
    try this if you want to handle in javascript. – Arpit Srivastava Jan 02 '20 at 11:59
  • @Liquidcore It’s actually the answer. 100% your problem occurred because of caching. no-store should work, explore your headers and update your question please – Alexander Selishchev Jan 02 '20 at 13:48
  • @ADOConnection - The issue / reason this might not be working is that OPs description sounds like the delete is happening on a different page than the "grid" from which delete was pressed. The wrong page is being cached by adding this after the delete and should be added to the page which is displaying the grid of objects (well both actually). – Tommy Jan 02 '20 at 15:00
  • @Tommy exactly, though this answer suggest to "uncache" delete page instead of grid, its within arm's reach to solve the OP problem. – Alexander Selishchev Jan 03 '20 at 00:44
  • @ADOConnection None of these works on Chrome. I had to move the logic which does the controls in another action called via ajax. In case of success, it returned the desired page, in case of errors it throws and error and Js handles it. – Liquid Core Feb 03 '20 at 07:59