unset() 和浏览器后退按钮的会话问题

发布于 2024-10-08 22:42:09 字数 1411 浏览 0 评论 0原文

我使用 SESSION 变量通过 PEAR 的 DB nextId()。由于我正在使用的遗留代码中存在范围问题，我将 I id 设置为会话变量。 INSERT 发生后，我使用 unset() 删除 SESSION 变量（这是清除已使用的记录id）。会话中还有更多信息保持不变，只是 next_id 元素被删除。

伪代码：

// Get the next Id and set to SESSION
$_SESSION['next_id'] = $db->nextId();

... more code here

// After insert
unset($_SESSION['next_id']);

我的问题是，单击浏览器上的后退按钮是否会以某种方式重置 SESSION 变量 $_SESSION['next_id']？也许导致它为NULL？在删除元素但用户返回到之前的状态后，CACHE 如何处理 SESSION？

编辑：问题的原因是生产中的代码（由任何用户）随机尝试使用 NULL 记录 id（这是 SESSION 中的 next_id）插入。只是尝试调试该过程，因为代码非常少，经过我的同行审查，并且刚刚难倒了我们？？？

编辑2：哇，我想我使用 SESSION 变量的方式有问题。好吧，我将尽可能解释为什么我选择这种方法。首先，代码正在从 PHP 4 重写，但当前的生产版本主要是 PHP 4，在 PHP 5 中新增了大量模块代码。我选择 SESSION 变量的原因是因为范围问题，需要在数百页遗留代码或一页上进行硬编码，并将值转换为所有页面都可以访问的 SESSION。（好吧，我的老板按照我选择的选项支付我的薪水）。最初的问题是他们（我的老板）想在插入信息之前向最终用户显示 id。因此，PEAR DB 调用 nextId()。我们使用 PostgreSQL，我使用记录 id 序列来确保下一个 id 是唯一的并且仅分配给最终用户（没有重复，因为 Postgres 处理在序列中锁定它）。因此，最终用户还可以在此过程中导航到多个页面，这也是另一个范围问题。现在，使用 SESSION 并通过一些验证和检查检索下一个 Id，整个过程大约需要 50 行代码，而不是按照正确方式编写的数千行代码。再说一次，这首先不是我的代码，只是以尽可能低的成本制定最佳解决方案。

如果您有另一个更好、更伟大、更简单、更便宜的解决方案，请随时发布。但如果你对我关于如何编码的决定感到不满，那么请支付我的账单，我将完全同意遵循更好的编码标准、实践和解决方案。

原文

I'm using a SESSION variable to set the pre-allocated record id from Postgres (getting the record id sequence) using PEAR's DB nextId(). I set the I id to a session variable because of scoping issues in the legacy code I'm working with. After the INSERT happens I use the unset() to remove the SESSION variable (This is to clear the used record id). There is more information in the session as well that remains intact, it's just the next_id element that is being removed.

Pseudo code:

// Get the next Id and set to SESSION
$_SESSION['next_id'] = $db->nextId();

... more code here

// After insert
unset($_SESSION['next_id']);

My question is, Would clicking the back button on the browser somehow reset the SESSION variable $_SESSION['next_id']? Maybe causing it to be NULL? How does CACHE handle the SESSION after an element has been removed but the user has returned to a previous state?

EDIT:
the reason for the question is that the code in production is randomly (by any user) trying to INSERT with a NULL record id (Which is the next_id from SESSION). Just trying to debug the process as the code is very minimal, reviewed by my peers and has just stumped us???

EDIT 2:
Wow I guess there is an issue with how I'm using the SESSION variable.
Well I'll explain as much as I can as to why I chose this method.
First the code is in the process on being rewritten from PHP 4, but the current production version is mostly PHP 4 with a ton a newly added module code in PHP 5.
The reason I chose the SESSION variable is because of a scoping issue that would need to be hard coded on several hundred pages of legacy code or on one page and cast the value into the SESSION which all pages have access to. (well my boss who pays my salary like the option I chose).
The original problem is they (my boss) wanted to display the id to the end user before the insertion of the information. Hence the PEAR DB call nextId(). We use PostgreSQL and I'm using the record id sequence to ensure that the next id will be unique and allocated to the end user only (No duplicates as Postgres handles locking this in the sequence).
So the end user can also navigate to multiple pages during the process, this also is another scoping issue.
Now using the SESSION and retrieving the next Id with some validation and checks is about 50 lines of code for the whole process instead of the thousands of lines of code that would have been written to do this the correct way.
Again NOT MY CODE in the first place, just making the best solution at the least possible cost.

If you have another, better, greater, easier, cheaper solution feel free to post away. But if you're going to piss on my decision about how to code, then please pay my bills and I will fully agree with following better coding standard,practices,solution.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

緦唸λ蓇 2024-10-15 22:42:09

无法想象您需要将 nextId() 存储在会话中以便在下一页上使用的场景。

正如 webbiedave 指出的 - $_SESSION 存储在服务器上，所以不 - 点击后退按钮不会“重置”会话变量。

但是，如果用户在第二页（清除 _SESSION 变量的页面）上点击刷新，您的脚本将再次启动，其中 next_id 设置为 null（因为它在上一页上设置为 nextId()），

如果用户点击后退按钮，上一页将从浏览器缓存中加载 - 没有向服务器发出请求，_SESSION 中没有 next_id 变量。

但是，如果将 nextId() 存储在 _SESSION 中，仍然会出现一些问题。

回复收藏 0 原文

豆芽 2024-10-15 22:42:09

如果 $_SESSION['next_id'] 出现 NULL，只需绕过所有插入，即使这意味着在到达您不想触及的遗留代码之前调用 die() 。

回复收藏 0 原文

遗弃Ｍ 2024-10-15 22:42:09

您确定会话本身没有在服务器端刷新吗？我在共享主机环境中遇到过这样的情况，其中服务器设置导致我的会话消失。我必须在我的应用程序中添加本地设置来克服这个问题（私有而不是公共会话存储）。

这些是我在 .htaccess 文件中为会话设置的设置，为它们提供了合理的磁盘存储时间

php_value session.gc_probability 1
php_value session.gc_divisor 100
php_value session.gc_maxlifetime 3600

Are you sure the session itself isn't being flushed on the server-side? I had a situation in a shared-hosting environment where the server settings were caused my sessions to disappear. I had to add local settings in my app to overcome this (private rather than common session storage).

These are the settings I have in my .htaccess file for the sessions, giving them reasonable time on the disk

php_value session.gc_probability 1
php_value session.gc_divisor 100
php_value session.gc_maxlifetime 3600

回复收藏 0 原文

愚人国度 2024-10-15 22:42:09

找到了问题的原因。最终用户在浏览器中打开多个选项卡，导致会话数据跨越任何打开的选项卡，因为他们都会调用同一会话。因此，在一个选项卡中提交一个请求会取消所有选项卡中的会话设置。因此，当他们在第二个选项卡中提交请求时，会话缺少 next_id 值，从而导致所有问题。用户培训暂时可以解决这个问题，但很快就会以新的方式实施。

感谢大家的努力

回复收藏 0 原文

~没有更多了~