javascript - 跨多个选项卡的亲子导航

Question

请忍受我的解释，这是必要的。

系统背景:
我正在为CMS的后端创建父/子导航系统。
我建立如下网址:[domain.ext]/[moduleName]/[objectName]/[actionName]/[ID #1]/[ID #2]。

解释的网址(例如example.com/PageManagement/Page/Modify/7/13):

moduleName :对象所属模块的名称(例如“PageManagement”)

objectName :对象的名称(例如“页面”)

actionName :操作的名称(例如“修改”)

ID＃1 :正在执行操作的记录的ID，或对象的父

的ID

ID＃2 :正在对其执行操作的记录的ID，但仅当ID＃1填充有父ID

时

通过解析其组件的URL，将名称简化为系统ID等，然后检索要在页面上显示的字段和数据，可以进行导航。
为了确保URL保持可读性和逻辑上的可理解性，我没有在URL上添加多层父ID，而是将最后几个父ID保留在PHP $_SESSION数组中，因此我可以在导航中确定是否必须使用其他父ID。被添加。

示例: image我们有对象 Page->Extension->Field，它们都在 PageManagement模块中，并且从左到右为父对象。现在假设我们有一个ID为2的页面，一个ID为8的扩展程序和一个ID为17的字段。用于编辑该字段的URL为 example.com/PageManagement/Field/Modify/8/17，因为我们正在编辑以扩展名为8的父级的Field 17。用于编辑扩展程序的URL为 example.com/PageManagement/Extension/Modify/2/8，因为我们正在编辑扩展程序8，其父级为Page 2。编辑页面将只是 example.com/PageManagement/Page/Modify/2，因为它没有父项。

问题:
现在，所有这些都完美地工作了。 但是，如果打开了多个选项卡，则会共享相同的 $_SESSION，因此在一个选项卡中导航可以抛弃另一个选项卡的父历史记录。在 几乎是的所有情况下，它仍然正确，但事实是我可能会感到很糟糕(因为有人可以添加/删除/编辑数据而又不知道它们实际上位于错误的父列表中)。

我需要什么:我需要一种针对每个请求的方法，以确定它来自哪个选项卡，最有可能的方式是为每个选项卡生成某种形式的UID并随每个请求发送。然后，我的系统可以按选项卡而不是按 session 存储导航历史记录。

考虑的解决方案

为每个页面 session 生成一个UID，并将其存储在Window.sessionStorage中(为每个新窗口/选项卡重置)。如果尚未设置任何内容(因此是一个新标签)，这将允许我生成一个，从而在每个页面 session 中存储(并记住)一个不同的内容。

问题:我不知道如何将每个请求的UID发送到服务器。 session cookie似乎在所有选项卡之间共享(这很有意义，因为它们共享一个 session )。

每个页面 session 生成一个UID，并将其作为查询字符串附加到URL。

问题:我也可能没有很好的URL，并且如果有人(偶然地)对其进行了编辑/删除，它将仍然无法使用。另外，复制/粘贴URL将是一个问题。

每个页面 session 生成一个UID，并将其放在moduleName之前的URL之前。

问题:它仍然是可见/可编辑/可移动的，如果这样做，仍然无法使用。另外，复制/粘贴URL将是一个问题。

如果有人可以解决上述解决方案中提到的问题，或者提出一个全新的解决方案，那就太好了。
显然，我希望对URL系统的工作方式进行尽可能少的更改，但是如果这是唯一的解决方案，那就...

Answer 1

您的请求设计中存在一个基本缺陷，正在引起您的所有麻烦。
系统应尽可能在单个请求中包括所有相关信息。在您的情况下，这意味着放弃在$_SESSION中“记住”较早请求(状态)的机制，而是传递请求中的所有信息。它可以在URL(“地址”和/或查询字符串)中，适当时的 header (通常使用cookie，在这种情况下可能不合适)或正文(与POSTed表单传递有效内容的方式相同)中。

选择此路径有很多原因，仅举几例:

改善日志记录。

轻松调试。

启用简单的，基于URL的链接(当仅将URL用于请求时)。

减少不正确缓存(本地或远程)的风险。

支持多个“同时”请求->将帮助解决当前问题:-)

像往常一样，没有规则没有异常(exception)。在这种情况下，不适合包含在每个请求中的最常见信息是身份验证信息(用户名，密码等)。

总而言之，您应该强烈考虑重新构造您的请求，以便所有必需的信息都可用。