1

I have a Django website that looks like this:

enter image description here

The arrows represent hyperlinks that take you to the next page. All pages except the Main Page need a "Back" button.

For Page A and Page B, the back button is pretty simple - it always takes you to the Main Page.

For Page C however, there are 2 different ways to get to it (technically 3, if you count the back button on Page D), so it's no longer obvious where the back button should take you.

The way it should work is this:

  • If the user came from Page A to get to Page C, the Back button should take them back to Page A
  • If the use came from Page B to get to Page C, the Back button should take them back to Page B
  • If the user didn't come from either Page A or Page B to get to Page C (they could have just entered the URL of Page C into their browser), default to having the Back button take them to Page A

This has been asked before, and none of the answers/suggestions make sense for anything other than the most basic scenario, where Page C is the end node.

The problem:

  • Using a hardcoded url for the back button of Page C won't work, because there are 2 ways to get to it
  • Using session to keep a single variable that keeps track of whether you last visited Page A or Page B won't work because multiple browser tabs share the same session variables. If the user has 2 tabs of our website open, navigating around will lead to confusion as both will update the same session variable
  • Using request.META.HTTP_REFERER won't work, because the user might navigate to Page D, and then back to Page C, so the HTTP_REFERER variable will point to Page D, rather than Page A or Page B
  • Using javascript:history.go(-1) won't work - same problem as above with HTTP_REFERER

I have come across this issue in multiple projects, and it's always a pain to deal with. The solution is always hacky. Is this a problem that inherently can't be handled by Django, and must be handled by something like JavaScript's sessionStorage?

John
  • 2,551
  • 3
  • 30
  • 55
  • Pass a parameter when linking to page C: `/page/c?from=b`. Then use that in the template or view to construct the back button as appropriate. – deceze Dec 25 '21 at 16:58
  • You need to store the HTTP_REFERE in session variable (request.session[] , create 2 vars, one in page C view request.session['pageC_PREF'] and this request.session['pageD_PREF'] in page D view, and do check there value in page C , in case page D is the preference of page C then request.session['pageD_PREF'] will show you if user came from page A,B or from outside, for outside and A options back will point to page A as per your scenario – Husam Alhwadi Dec 25 '21 at 17:25
  • @deceze As soon as I go to page D, and return to C, the parameter is gone. I'd have to propagate the parameter to page D, and every page below it. Every page below page D would need to have custom code that would handle this parameter, propagating it to every other page. That sounds like a massive pain. – John Dec 25 '21 at 19:39
  • @HusamAlhwadi if I understand you correctly, your proposed solution doesn't solve the fact that there's one session per client - not per browser tab. Having 2 browser tabs open, each navigating around, will confuse the website. The session variable set by one tab will override the other, and vice versa – John Dec 25 '21 at 19:41
  • Then its better to handle it at client side via 2 ajax calls , one for getting tab id using tabs.get() along with current url and store them in bakend, another ajax call to fetch them and assign the proper destination for back button accordingly , whatever solution either this way or via customising session; Tab id is required – Husam Alhwadi Dec 25 '21 at 20:51
  • Javascript history doesn't work reliably with reloading pages and such. HTTP referer is notoriously unreliable and would need to be passed forward beyond one page as well. Sessions aren't window-specific. You *must* pass something in the URL to address all those different concerns. If you need to remember history even further than one page, then pass basically a "session id" in the URL, but save the visiting history server-side. Yes, it's a massive pain, but you've chosen this for yourself… – deceze Dec 25 '21 at 20:56

0 Answers0