session_regenerate_id()

(PHP 4 >= 4.3.2, PHP 5, PHP 7)

使用新生成的会话 ID 更新现有会话ID

说明

session_regenerate_id()在不修改当前会话中数据的前提下使用新的 ID 替换原有会话 ID。

如果启用了 session.use_trans_sid 选项，那么必须在调用session_regenerate_id()函数之后开始进行输出工作，否则会导致使用原有的会话 ID。

当前的 session_regenerate_id 并没有很好的处理在诸如移动数据网络和 WiFi 网络不稳定的场景。因此，调用 session_regenerate_id 函数可能会导致会话丢失。

你不应该直接销毁旧的会话所关联的数据，而是应该使用时间戳机制来控制对于已经失效的会话 ID 的访问。否则，可能会在并发访问的场景下导致会话数据不一致、会话丢失等情况，甚至可能引发客户端（浏览器）创建很多无用的会话 ID。但是，另外一方面来讲，立即删除会话中的数据可以防止会话劫持攻击。

参数

$delete_old_session

是否删除原 ID 所关联的会话存储文件。如果你需要避免会话并发访问冲突，那么不应该立即删除会话中的数据。如果你需要防止会话劫持攻击，那么可以立即删除会话数据。

返回值

成功时返回TRUE，或者在失败时返回FALSE。

更新日志

范例

Asession_regenerate_id()示例

当前的会话模块未能很好的处理在网络不稳定的时候导致会话丢失的场景。你需要自行管理会话 ID 避免调用 session_regenerate_id 导致会话丢失。

Avoiding lost session bysession_regenerate_id()

参见

• session_id()获取/设置当前会话 ID
• session_create_id()Create new session id
• session_start()启动新会话或者重用现有会话
• session_destroy()销毁一个会话中的全部数据
• session_reset()Re-initialize session array with original values
• session_name()读取/设置会话名称

In PHP 5.6 (and probably older versions), session_regenerate_id(true) do not trigger a read() call to the session handler for the new session id. 
In PHP 7, read() is triggered during session_regenerate_id(true). Nice to know when working with custom session handlers.

In a previous note, php at 5mm de describes how to prevent session hijacking by
ensuring that the session id provided matches the HTTP_USER_AGENT and REMOTE_ADDR fields that were present when the session id was first issued. It should be noted that HTTP_USER_AGENT is supplied by the client, and so can be easily modified by a malicious user. Also, the client IP addresses can be spoofed, although that's a bit more difficult. Care should be taken when relying on the session for authentication.

I wrote the following code for a project I'm working on- it attempts to resolve the regenerate issue, as well as deal with a couple of other session related things.
I tried to make it a little more generic and usable (for instance, in the full version it throws different types of exceptions for the different types of session issues), so hopefully someone might find it useful.

Since "microtime" is predictable it makes brute forcing the nonce much easier. A better option would be something that utilizes randomness, such as- 

If you are trying to maintain 2 active sessions don't use session_regenerate_id(). Especially if the first session is closed and it's time to open the second. Because the session id is cached you also have to explicitly set it the second time.

To start a new session and leave the old untouched, simply leave out the argument to `session_regenerate_id`.

I had problems with a proxy changing a visitors session_id-cookie, so he'd get a LOT of errors when visiting my site.
I handled the bogus session-id's like this. (Note: It only works in versions > 4.3.2.)

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com