Parent-child navigation in multiple tabs

Question

please refrain from explaining me, this is necessary.

System Background: I create a parent> child navigation system for the CMS backend. I create the following URLs: [domain.ext]/[moduleName]/[objectName]/[actionName]/[ID #1]/[ID #2] .

Specified URL (e.g. example.com/PageManagement/Page/Modify/7/13 ):

• moduleName : name of the module the object belongs to (for example, "PageManagement")
• objectName : object name (for example, "Page")
• actionName : name of the action (for example, "Edit")
• ID # 1 : either the identifier of the record in which the action is performed , or the identifier of the parent
• ID # 2 : identifier of the record in which the action is performed, but only if ID # 1 is filled with the parent identifier

Navigation occurs by parsing the URLs for its components, decreasing the names for system identifiers, etc., and then obtaining the fields and data that should be displayed on the page.
To keep the URL legible and logical, I don’t add a few parent identifier URLs to the URL, but I save the last few parent identifiers in the PHP $_SESSION , so I can determine if another parent identifier should be added when navigating.

Example:. We have Page->Extension->Field objects, all of which are in the PageManagement module and are pending from left to right. Now suppose we have a page with id 2, an extension with id 8 and a field with id 17. The URL to edit the field will be example.com/PageManagement/Field/Modify/8/17 , because we are editing field 17. which has an extension of 8 as a parent. The URL for editing the extension will be example.com/PageManagement/Extension/Modify/2/8 , because we are editing extension 8, which has a parent. Editing the page will be just example.com/PageManagement/Page/Modify/2 , because it does not have a parent.

Problem: Now it all works great. However , if multiple tabs are opened, they have the same $_SESSION , so switching to one tab may discard the parent history for the other tab. It still works in almost all cases, but the fact that I can do it is bad (since someone can add / delete / edit data without knowing that they really are in the wrong list of parents).

What I need: I need, with each request, to determine which tab it came from, most likely by creating some form of UID for each tab and sending it with each request. My system can then save the navigation history for each tab, not per session.

Considered Solutions

• Create a UID session on the page and save it in Window.sessionStorage (which gets reset for each new window / tab). This will allow me to generate one if none is set (so there is a new tab), and therefore has another stored (and remembered) session on the page.
  • Problem: I do not know how I can get this UID sent to the server with every request. Session cookies seem to be shared between all the tabs (it makes sense since they share the session).
• Create a UID session on the page and add this URL to the query string.
  • Problem: I can also have good URLs, and if someone (accidentally) edits / deletes it, it still won't work. Also, copying / pasting the url will be a problem.
• Create a UID session on the page and add this URL before moduleName .
  • Problem: It is still visible / edited / deleted, and if they do, it will still not work. Also, copying / pasting the url will be a problem.

If someone can solve the problems mentioned above for solutions, or come up with a completely new solution, it will be awesome. Obviously, I would prefer to make as few changes as possible how the URL system works, but if this is the only solution, let it be ...

Answer 1

There is a major flaw in the design of your request, which causes you all the problems.
The system should strive to include all relevant information within a single request, whenever possible. In your case, this means disabling the mechanism, which “remembers” earlier requests (state ..) in $_SESSION and instead passes all the information in the request. It can be in a URL ("address" and / or request string), headers when necessary (usually using cookies, perhaps inappropriate in this case), or body (just like POSTed forms transmit a payload) .

There are many reasons for choosing this path, to name a few:

• Improved logging.
• Easy debugging.
• Include a simple URL-based link (when using only URLs for requests).
• Reduce the risk of incorrect caching (local or remote).
• Support for multiple "simultaneous" requests → Helps overcome the current problem :-)

As always, no rule applies to exceptions. In this case, the most common piece of information that is NOT suitable for inclusion in each request is authentication information (username, password, etc.)

To summarize, you should strongly consider restoring your requests so that all the necessary information is available.