Session Handling
- 简介
- 安装／配置
- 需求
- 安装
- 运行时配置
- 资源类型
- 预定义常量
- 范例
- 基本用法
- 传送会话ID
- 自定义会话管理器
- Session 上传进度
- 会话和安全
- Session 函数
- session_abort — Discard session array changes and finish session
- session_cache_expire — 返回当前缓存的到期时间
- session_cache_limiter — 读取/设置缓存限制器
- session_commit — session_write_close 的别名
- session_decode — 解码会话数据
- session_destroy — 销毁一个会话中的全部数据
- session_encode — 将当前会话数据编码为一个字符串
- session_get_cookie_params — 获取会话 cookie 参数
- session_id — 获取/设置当前会话 ID
- session_is_registered — 检查变量是否在会话中已经注册
- session_module_name — 获取/设置会话模块名称
- session_name — 读取/设置会话名称
- session_regenerate_id — 使用新生成的会话 ID 更新现有会话 ID
- session_register_shutdown — 关闭会话
- session_register — Register one or more global variables with the current session
- session_reset — Re-initialize session array with original values
- session_save_path — 读取/设置当前会话的保存路径
- session_set_cookie_params — 设置会话 cookie 参数
- session_set_save_handler — 设置用户自定义会话存储函数
- session_start — 启动新会话或者重用现有会话
- session_status — Returns the current session status
- session_unregister — Unregister a global variable from the current session
- session_unset — Free all session variables
- session_write_close — Write session data and end session
- SessionHandler — The SessionHandler class
- SessionHandler::close — Close the session
- SessionHandler::create_sid — Return a new session ID
- SessionHandler::destroy — Destroy a session
- SessionHandler::gc — Cleanup old sessions
- SessionHandler::open — Initialize session
- SessionHandler::read — Read session data
- SessionHandler::write — Write session data
- SessionHandlerInterface — The SessionHandlerInterface class
- SessionHandlerInterface::close — Close the session
- SessionHandlerInterface::destroy — Destroy a session
- SessionHandlerInterface::gc — Cleanup old sessions
- SessionHandlerInterface::open — Initialize session
- SessionHandlerInterface::read — Read session data
- SessionHandlerInterface::write — Write session data
用户评论:
[#1] bouvrette dot nicolas at gmail dot com [2014-11-23 21:43:42]
Be careful if you are updating to PHP 5.6 since the the Sessions's Write behavior changed. It now only writes the session if you changed the data. So this means that if you rely on your session to update an activity time stamp on the server (to control session expiry) you will end up having issues. Here is a quick fix if you are implementing SessionHandlerInterface:
public function close() {
$this->write($this->id, serialize($_SESSION));
return true;
}
Make sure you also use this:
ini_set('session.serialize_handler', 'php_serialize'); // Force standard PHP functions handler for flexibility
More details here:
Request #17860 (Session write short circuit)
https://bugs.php.net/bug.php?id=17860
[#2] roberto at spadim dot com dot br [2011-03-20 22:28:25]
instead of memcache, you should consider using redis
http://redis.io/commands
it have KEYS command (http://redis.io/commands/keys) that can return all keys (like 'ls'/'dir' at php sessions directory)
it allow replication too (cluster use)
i don't know if anyone wrote a version of phpsessions using redis yet, but since memcache don't have KEYS command, it's hard to know if the users is connected (at app side) or what sessions still active (not expired/not logged)
[#3] elephant at punx dot pl [2011-02-28 11:51:39]
Please note, that database is NOT recommended for session storage. It can be a big performance bottleneck, especially in replicated environments.
For saving sessions, file handler seems to be very effective for most setups, except those situations:
- if performance is an issue, the directory which stores session files can be mounted as tmpfs (ram disk).
- if sharing sessions across multiple webservers is needed (in clustered environments), use memcache for storing session information (tip: you can setup more than one instance of memcache eliminate single point of failure). This method, however, sets a limitation of session size to 64k (this should be enough for most applications)
- don't use NFS for sharing session files between webservers, it does not handle locking correctly and can cause corruption of session data.
[#4] e dot mortoray at ecircle dot com [2009-04-17 05:02:31]
There is a nuance we found with session timing out although the user is still active in the session. The problem has to do with never modifying the session variable.
The GC will clear the session data files based on their last modification time. Thus if you never modify the session, you simply read from it, then the GC will eventually clean up.
To prevent this you need to ensure that your session is modified within the GC delete time. You can accomplish this like below.
<?php
if( !isset($_SESSION['last_access']) || (time() - $_SESSION['last_access']) > 60 )
$_SESSION['last_access'] = time();
?>
This will update the session every 60s to ensure that the modification date is altered.
[#5] Some Guy [2009-01-16 04:26:11]
Just some notes - it seems that php does the session writing after the script exits.
For example, if you set a bunch of session variables and then run session_regenerate_id() - the session variables are never written to the old session. The new session id is generated when you ask it to be generated, but the session exists only in memory until after the script exits - when the session is written and any and all session variables are written to it.
This caused me some confusion, as I'm running sessions in an sql database rather than flat file, trying to do any manipulation of the session database directly in a script where you have run session_regenerate_id() will fail for the new session ID because the insert hasn't been done yet, and setting any session variables will only be written to the new session, even if set before you regenerate the session ID.
Also - if using a database for sessions, make sure to use mysql_real_escape_string() before saving any session variables.
[#6] Madster [2008-07-28 12:45:11]
When you include a php file in your current script it's included, not processed separately, thus it's still within the same page and the current page hasn't finished processing.
Thus, session is not set yet. This is the expected behaviour.
If you need to load a page after setting session data, you should set session data and then send a redirection or refresh header (remember not to send anything, not even whitespace before sending headers).
Always consider session data to be updated after the next page load (as in http request completed).