php实现SESSION跨域 php实现SESSION跨域稍微大一点的网站，通常都会有不只一个服务器，每个服务器运行着不同的功能模块或者不同的子系统，他们使用不同的二级域名，比如www.a.com、 i.a.com、bbs.a.com。而一个整体性强的网站，用户系统是统一的，即一套用户名、密码在整个网站的各个子系统中都是可以登录使用的。各个服 务器共享用户数据是比较容易实现的，只需要在后端放个数据库服务器，各个服务器通过统一接口对用户数据进行访问即可。但还存在一个问题，就是用户在 i.a.com登录之后，进入www.a.com时，仍然需要重新登录，基本的通行证的问题，映射到技术上，其实就是各个服务器之间如何实现共享 SESSION 数据的问题。为了解决这个问题，我们采用将 SESSION 的数据保存数据库的方式。关于PHP SESSION的扫盲这里就不在累赘。在默认情况下，各个服务器会各自分别对同一个客户端产生 SESSION ID，如对于同一个用户浏览器，www.a.com系统产生的session id是a0211e9de3192ba6c22992d27a1b6a0a，而i.a.com生成的则是 277003f262f0c366946a86a28ba431d8。另外，PHP 的 SESSION 数据都是分别保存在本服务器的文件系统中。想要共享 SESSION 数据，那就必须实现两个目标：www.a.com和i.a.com所产生的SESSION ID相同，并且可通过同一个 COOKIE 进行传递，也就是说各个服务器必须可以读取同一个名为 PHPSESSID 的 COOKIE；另一个是 SESSION 数据必须存放在一个各个系统都能访问到的地方。简单地说就是多服务器共享客户端的 SESSION ID，同时还必须共享服务器端的 SESSION 数据。第一个目标的实现其实很简单，只需要对 COOKIE 的域（domain）进行特殊地设置即可，默认情况下，COOKIE 的域是当前服务器的域名/IP 地址，而域不同的话，各个服务器所设置的 COOKIE 是不能相互访问的，如 www.a.com 的服务器是不能读写 www.b.com 服务器设置的 COOKIE 的。这里我们所说的同一网站的服务器有其特殊性，那就是他们同属于同一个一级域，如：www.a.com 和 i.a.com 都属于域 .a.com，那么我们就可以设置 COOKIE 的域为 .a.com，这样 www.a.com、i.aaa.com 等等都可以访问此 COOKIE。PHP 代码中的设置方法如下：1 ini_set('session.cookie_domain', '.a.com');这样各个系统共享同一客户端 SESSION ID 的目的就达到了，下面就是共享SESSION数据，我们就将SESSION数据放在数据库中，首先建立数据库表：1 CREATE TABLE sessions (2 session_id varchar(32) NOT NULL,3 session_last_access int(10) unsigned,4 session_data text,5 PRIMARY KEY (session_id)session_id为主键，保存SESSION ID ，session_last_access是SESSION最后更新时间，session_data是SESSION数据。PHP 提供了session_set_save_handle() 函数，可以用此函数自定义 SESSION 的处理过程，当然首先要先将 session.save_handler 改成 user，可在 PHP 中进行设置：接下来着重讲一下 session_set_save_handle() 函数，此函数有六个参数：session_set_save_handler ( string open, string close, string read, string write, string destroy, string gc )各个参数为各项操作的函数名，这些操作依次是：打开、关闭、读取、写入、销毁、垃圾回收。

PHP Session可能会引起并发问题 PHP Session可能会引起并发问题　在进行Web应用程序开发的时候，人们经常会用Session存储数据。但可能有人不知道，在PHP中，Session使用不当可能会引起并发问题。印度医疗行业软件解决方案提供商Plus91 Technologies高级工程师Kishan Gor在个人博客上对这个问题进行了阐释。　　如果同一个客户端并发发送多个请求，而每个请求都使用了Session，那么PHP Session锁的存在会导致服务器串行响应这些请求，而不是并行。这是因为在默认情况下，PHP使用文件存储Session数据。对于每一个新的Session，PHP会创建一个文件，并持续向其中写入数据。所以，每次调用session_start（）方法，就会打开Session文件，并取得文件的独占锁。这样，如果服务器脚本正在处理一个请求，而客户端又发送了一个同样需要使用Session的请求，那么后一个请求会阻塞，直至前一个请求处理完成释放了文件上的独占锁。不过，这只限于来自同一个客户端的多个请求，也就是说，来自一个客户端的请求并不会阻塞另一个客户端的请求。　　　如果脚本很短，这通常没有问题。但如果脚本运行时间比较长，那就可能会产生问题。在现代Web应用程序开发中，有一个非常常见的情况，就是使用AJAX技术在同一个页面内发送多个请求获取数据。如果这些请求都需要使用Session，那么第一个请求到达服务器后会取得Session锁，其它请求就必须等待，所有请求将串行处理，即使它们彼此之间并没有依赖关系。这将大大增加页面的响应时间。　有一个方法可以避免这个问题，就是在使用完Session以后立即调用session_write_close（）方法关闭Session。这样Session锁就会释放，即使当前脚本还在等在处理。需要注意的是，调用该方法后，当前脚本就不能进一步操作Session了。　　需要特别指出的是，本文所陈述的问题和观点只适用于使用session_start（）方法的PHP默认Session管理模式。比如，有用户就指出，如果将应用程序托管在AWS EC2上，并正确配置DynamoDB，Session锁定问题就不会出现。

Session的本质 Session的本质有一点我们必须承认，大多数web应用程序都离不开session的使用。这篇文章将会结合php以及http协议来分析如何建立一个安全的会话管理机制。我们先简单的了解一些http的知识，从而理解该协议的无状态特性。然后，学习一些关于cookie的基本操作。最后，我会一步步阐述如何使用一些简单，高效的方法来提高你的php应用程序的安全性以及稳定行。我想大多数的php初级程序员一定会认为php默认的session机制的安全性似乎是有一定保障的，事实恰好相反 – php团队只是提供了一套便捷的session的解决方案提供给程序员使用，至于安全性的话，应该由程序员来加强，这是应用程序开发团队的责任。因为，这里面的方法很多，可以这么说吧，没有最好，只有更好。攻击的方式在不断变化，防守方也需要不断变招，所以，我个人认为php团队的做法还是比较明智的。无状态性Http是一种无状态性的协议。这是因为此种协议不要求浏览器在每次请求中标明它自己的身份，并且浏览器以及服务器之间并没有保持一个持久性的连接用于多个页面之间的访问。当一个用户访问一个站点的时候，用户的浏览器发送一个http请求到服务器，服务器返回给浏览器一个http响应。其实很简单的一个概念，客户端一个请求，服务器端一个回复，这就是整个基于http协议的通讯过程。因为web应用程序是基于http协议进行通讯的，而我们已经讲过了http是无状态的，这就增加了维护web应用程序状态的难度, 对于开发者来说，是一个不小的挑战。Cookies是作为http的一个扩展诞生的，其主要用途是弥补http的无状态特性，提供了一种保持客户端与服务器端之间状态的途径，但是由于出于安全性的考虑，有的用户在浏览器中是禁止掉cookie的。这种情况下，状态信息只能通过url中的参数来传递到服务器端，不过这种方式的安全性很差。事实上，按照通常的想法，应该有客户端来表明自己的身份，从而和服务器之间维持一种状态，但是出于安全性方面的考虑，我们都应该明白一点 – 来自客户端的信息都是不能完全信任的。尽管这样，针对维持web应用程序状态的问题，相对来说，还是有比较优雅的解决方案的。不过，应该说是没有完美的解决方案的，再好的解决方案也不可能适用所有的情况。这篇文章将介绍一些技术。这些技术可以用来比较稳定地维持应用程序的状态以及抵御一些针对session的攻击，比如会话劫持。并且你可以学习到cookie是怎样工作的，php 的session做了那些事情，以及怎样才能劫持session。HTTP 概览如何才能保持web应用程序的状态以及选择最合适的解决方案呢?在回答这个问题之前，必须得先了解web的底层协议 – Hypertext Transfer Protocol (HTTP)。当用户访问http://example.com这个域名的时候，浏览器就会自动和服务器建立tcp/ip连接，然后发送http请求到example.com的服务器的80端口。该个请求的语法如下所示：GET / HTTP/1.1Host: example.org以上第一行叫做请求行，第二个参数(一个反斜线在这个例子中)表示所请求资源的路径。反斜线代表了根目录;服务器会转换这个根目录为服务器文件系统中的一个具体目录。Apache的用户常用DocumentRoot这个命令来设置这个文档根路径。如果请求的url是http://example.org/path/to/script.php,那么请求的路径就是/path/to/script.php。假如document root 被定义为usr/lcoal/apache/htdocs的话,整个请求的资源路径就是/usr/local/apache/htdocs/path/to/script.php。第二行描述的是http头部的语法。在这个例子中的头部是Host, 它标识了浏览器希望获取资源的域名主机。还有很多其它的请求头部可以包含在http请求中，比如user-Agent头部，在php可以通过$_SERVER['HTTP_USER_AGENT']获取请求中所携带的这个头部信息。但是遗憾的是，在这个请求例子中，没有任何信息可以唯一标识当前这个发出请求的客户端。有些开发者借助请求中的ip头部来唯一标识发出此次请求的客户端，但是这种方式存在很多问题。因为，有些用户是通过代理来访问的，比如用户A通过代理B连接网站www.example.com, 服务器端获取的ip信息是代理B分配给A的ip地址，如果用户这时断开代理，然后再次连接代理的话，它的代理ip地址又再次改变，也就说一个用户对应了多个ip地址，这种情况下，服务器端根据ip地址来标识用户的话，会认为请求是来自不同的用户，事实上是同一个用户。 还用另外一种情况就是，比如很多用户是在同一个局域网里通过路由连接互联网，然后都访问www.example.com的话，由于这些用户共享同一个外网ip地址，这会导致服务器认为这些用户是同一个用户发出的请求，因为他们是来自同一个ip地址的访问。保持应用程序状态的第一步就是要知道如何来唯一地标识每个客户端。因为只有在http中请求中携带的信息才能用来标识客户端，所以在请求中必须包含某种可以用来标识客户端唯一身份的信息。Cookie设计出来就是用来解决这一问题的。Cookies如果你把Cookies看成为http协议的一个扩展的话，理解起来就容易的多了，其实本质上cookies就是http的一个扩展。有两个http头部是专门负责设置以及发送cookie的,它们分别是Set-Cookie以及Cookie。当服务器返回给客户端一个http响应信息时，其中如果包含Set-Cookie这个头部时，意思就是指示客户端建立一个cookie，并且在后续的http请求中自动发送这个cookie到服务器端，直到这个cookie过期。如果cookie的生存时间是整个会话期间的话，那么浏览器会将cookie保存在内存中，浏览器关闭时就会自动清除这个cookie。另外一种情况就是保存在客户端的硬盘中，浏览器关闭的话，该cookie也不会被清除，下次打开浏览器访问对应网站时，这个cookie就会自动再次发送到服务器端。一个cookie的设置以及发送过程分为以下四步：客户端发送一个http请求到服务器端服务器端发送一个http响应到客户端，其中包含Set-Cookie头部客户端发送一个http请求到服务器端，其中包含Cookie头部服务器端发送一个http响应到客户端这个通讯过程也可以用以下下示意图来描述：在客户端的第二次请求中包含的Cookie头部中，提供给了服务器端可以用来唯一标识客户端身份的信息。这时，服务器端也就可以判断客户端是否启用了cookies。尽管，用户可能在和应用程序交互的过程中突然禁用cookies的使用，但是，这个情况基本是不太可能发生的，所以可以不加以考虑，这在实践中也被证明是对的。GET and POST Data除了cookies,客户端还可以将发送给服务器的数据包含在请求的url中，比如请求的参数或者请求的路径中。 我们来看一个例子：GET /index.php?foo=bar HTTP/1.1Host: example.org以上就是一个常规的http get 请求，该get请求发送到example.org域名对应的web 服务器下的index.php脚本, 在index.php脚本中，可以通过$_GET['foo']来获取对应的url中foo参数的值，也就是’bar’。大多数php开发者都称这样的数据会GET数据，也有少数称它为查询数据或者url变量。但是大家需要注意一点，不是说GET数据就只能包含在HTTP GET类型的请求中，在HTTP POST类型的请求中同样可以包含GET数据，只要将相关GET数据包含在请求的url中即可，也就是说GET数据的传递不依赖与具体请求的类型。另外一种客户端传递数据到服务器端的方式是将数据包含在http请求的内容区域内。 这种方式需要请求的类型是POST的，看下面一个例子：POST /index.php HTTP/1.1Host: example.orgContent-Type: application/x-www-form-urlencodedContent-Length: 7foo=bar在这种情况下，在脚本index.php可以通过调用$_POST['foo']来获取对应的值bar。开发者称这个数据为POST数据,也就是大家熟知的form以post方式提交请求的方式。在一个请求中，可以同时包含这两种形式的数据：POST /index.php?myget=foo HTTP/1.1Host: example.orgContent-Type: application/x-www-form-urlencodedContent-Length: 11mypost=bar这两种传递数据的方式，比起用cookies来传递数据更稳定，因为cookie可能被禁用，但是以GET以及POST方式传递数据时，不存在这种情况。我们可以将PHPSESSID包含在http请求的url中，就像下面的例子一样：GET /index.php?PHPSESSID=12345 HTTP/1.1Host: example.org以这种方式传递session id的话，可以跟用cookie头部传递session id一样，达到同样的效果， 但是，缺点就是需要开发者认为地将session id附加在url中或者作为隐藏字段加入到表单中。不像cookie一样，只要服务器端指示客户端创建cookie成功以后，客户端在后续的请求中，会自动第将对应的没有过期的cookie传递给服务器端。当然，php在开启session.use_trans_sid后，也可以自动地将session id 附加在url中以及表单的隐藏字段中，但是这个选项不建议开启，因为存在安全问题。这样的话，容易泄露session id, 比如有的用户会bookmark一个url或者分享一个url，那么session id也就暴露了，加入这个session id还没有过期，那是有一定的安全问题存在的，除非服务器端，除了session id外，还附加了其它方式进行验证用户的合法性!尽管以POST的方式来传递session id的话，相对GET的方式来说，会安全的多。但是，这种方式的缺点就是比较麻烦，因为这样的话，在你的应用程序中比较将所有的请求都转换成post的请求，这显然是不太合适的。Session的管理直到现在，我只讨论了如何维护应用程序的状态，只是简单地涉及到了如果保持请求之间的关系。接下来，我阐述下在实际中用到比较多的技术 – Session的管理。涉及到session的管理，就不是单单地维持各个请求之间的状态，还需要维持会话期间针对每个特定用户使用到的数据。我们常常把这种数据叫做session数据，因为这些数据是跟某个特定用户与服务器之间的会话相关联的。如果你使用php内置的session的管理机制，那么session数据一般是保存在/tmp这个服务器端的文件夹中，并且其中的session数据会被自动地保存到超级数组$_SESSION中。一个最简单的使用session的例子，就是将相关的session数据从一个页面传递(注意：实际传递的是session id)到另一个页面。下面用示例代码1, start.php, 对这个例子加以演示：<?php session_start(); $_SESSION['foo'] = 'bar'; ?> continue.php 假如用户点击start.php中的链接访问continue.php,那么在continue.php中就可以通过$_SESSION['foo']获取在start.php中的定义的值’bar’。看下面的示例代码2:示例代码2 – continue.php<?php session_start(); echo $_SESSION['foo']; / bar / ?> 是不是非常简单，但是我要指出的话，如果你真的这样来写代码的话，说明你对php底层的对于session的实现机制还不是非常了解透彻。在不了解php内部给你自动做了多少事情的情况下，你会发现如果程序出错的话，这样的代码将变的很难调试，事实上，这样的代码也完全没有安全性可言。Session的安全性问题一直以来很多开发者都认为php内置的session管理机制是具有一定的安全性，可以对一般的session攻击起到防御。事实上，这是一种误解，php团队只实现了一种方便有效的机制。具体的安全措施，应该有应用程序的开发团队来实施。 就像开篇谈到的，没有最好的解决方案，只有最合适你的方案。现在，我们来看下一个比较常规的针对session的攻击：用户访问http://www.example.org，并且登录。example.org的服务器设置指示客户端设置相关cookie – PHPSESSID=12345攻击者这时访问http://www.example.org/,并且在请求中携带了对应的cookie – PHPSESSID=12345这样情况下，因为example.orge的服务器通过PHPSESSID来辨认对应的用户的，所以服务器错把攻击者当成了合法的用户。整个过程的描述，请看下面的示例图：当然这种攻击的方式，前提条件是攻击者必须通过某种手段固定，劫持或者猜测出某个合法用户的PHPSESSID。虽然这看起来难度很高，但是也不是不可能的事情。安全性的加强有很多技术可以用来加强Session的安全性，主要思想就是要使验证的过程对于合法用户来说，越简单越好，然后对于攻击者来说，步骤要越复杂越好。当然，这似乎是比较难于平衡的，要根据你应用程序的具体设计来做决策。最简单的居于HTTP/1.1请求包括请求行以及一些Host的头部：GET / HTTP/1.1Host: example.org如果客户端通过PHPSESSID传递相关的session标识符，可以将PHPSESSID放在cookie头部中进行传递:GET / HTTP/1.1Host: example.orgCookie: PHPSESSID=12345同样地，客户端也可以将session标识符放在请求的url中进行传递。GET /?PHPSESSID=12345HTTP/1.1Host: example.org当然，session标识符也可以包含在POST数据中，但是这对用户体验有影响，所以这种方式很少采用。因为来自TCP/IP信息也不一定可以完全信任的，所以，对于web开发者来说，利用TCP/IP中的信息来加强安全性也是不太合适的。 不过，攻击者也必须提供一个合法用户的唯一的标识符，才能假扮成合法用户进入系统。因此，看起来唯一能够有效的保护系统的措施，就是尽量地隐藏session标识符或者使之难于猜测出来。最好就是两者都能实施。PHP会自动生成一个随机的session ID，基本来说是不可能被猜测出来的，所以这方面的安全还是有一定保障的。但是，要防止攻击者获取一个合法的session ID是相当困难的，这基本上不是开发者所能控制的。事实上，许多情况下都有可能导致session ID的泄露。 比如说，如果通过GET数据来传递session ID的话，就有可能暴露这个敏感的身份信息。因为，有的用户可能会将带有session ID的链接缓存，收藏或者发送在邮件内容中。Cookies是一种像相对来说安全一点的机制，但是用户是可以在客户端中禁止掉cookies的!在一些IE的版本中也有比较严重的安全漏洞，比较有名的就是会泄露cookies给一些有安全隐患的邪恶站点。因此，作为一个开发者，可以肯定session ID是不能被猜测出来的，但是还是有可能被攻击者使用某些方法获取到。所以，必须采取一些额外的安全措施来防止此类情况在你的应用程序中发生。实际上，一个标准的HTTP请求中除了Host等必须包含的头部，还包含了一些可选的头部.举一个例子，看下面的一个请求：GET / HTTP/1.1Host: example.orgCookie: PHPSESSID=12345User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1Accept: text/html;q=0.9, /;q=0.1Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66Accept-Language: en我们可以看到，在以上的一个请求例子中包含了四个额外的头部，分别是User-Agent, Accept, Accept-Charset以及Accept-Language。因为这些头部不是必须的，所以完全依赖他们在你的应用程序中发挥作用是不太明智的。但是，如果一个用户的浏览器确实发送了这些头部到服务器，那么可以肯定的是在接下来的同一个用户通过同一个浏览器发送的请求中，必然也会携带这些头部。当然，这其中也会有极少数的特殊情况发生。假如以上例子是由一个当前的跟服务器建立了会话的用户发出的请求，考虑下面的一个请求：GET / HTTP/1.1Host: example.orgCookie: PHPSESSID=12345User-Agent: Mozilla/5.0因为有相同的session id包含在请求的Cookie头部中，所以相同的php session将会被访问到。但是，请求里的User-Agent头部跟先前的请求中的信息是不同的，系统是否可以假定这两个请求是同一个用户发出的?像这种情况下，发现浏览器的头部改变了，但是不能肯定这是否是一次来自攻击者的请求的话，比较好的措施就是弹出一个要求输入密码的输入框让用户输入，这样的话，对用户体验的影响不会很大，又能很有效地防止攻击。当然，你可以在系统中加入核查User-Agent头部的代码，类似示例3中的代码：示例代码3<?php session_start(); if (md5($_SERVER['HTTP_USER_AGENT']) != $_SESSION['HTTP_USER_AGENT']) {  / 弹出密码输入框 /  exit; } ?> 当然，你先必须在第一次请求时，初始化session的时候，用MD5算法加密user agent信息并且保存在session中，类似下面示例4中的代码：示例代码4<?php session_start(); $_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']); ?> 虽然不一定需要用MD5来加密这个User-Agent信息，但使用这种方式以后就不需要再过滤这个$_SERVER['HTTP_USER_AGENT']数据了。不然的话，在使用这个数据以前必须要进行数据过滤，因为任何来自客户端的数据都是不可信任的，必须要注意这一点。在你检查这个User-Agent客户端头部信息以后，做为一个攻击者必须要完成两步才能劫持一个session:获取一个合法的session id包含一个相同的User-Agent头部在伪造的请求中你可能会说，居然攻击者能获得有效的session id,那么以他的水平，伪造一个相同的User-Agent不是件难事。不错，但是我们可以说这至少给他添加了一些麻烦，在一定程度上也增加了session机制的安全性。你应该也能想到了，既然我们可以检查User-Agent这个头部来加强安全性，那么不妨再利用其它的一些头部信息，把他们组合起来生成一个加密的token，并且让客户端在后续的请求中携带这个token!这样的话，攻击者基本上不可能猜测出这样一个token是怎么生成出来的。这好比你用信用卡在超市付款，一个你必须有信用卡(好比session id)，另外你也必须输入一个支付密码(好比token),这有这两者都符合的情况下，你才能成功进入账号付款。 看下面一段代码：<?php session_start(); $token = 'SHIFLETT' . $_SERVER['HTTP_USER_AGENT']; $_SESSION['token'] = md5($token . session_id()); ?> 注意：Accept这个头部不应该被用来生成token,因为有些浏览器会自动改变这个头部，当用户刷新浏览器的时候。 在你的验证机制中加入了这个非常难于猜测出来的token以后，安全性会得到很大的提升。假如这个token通过像session id一样的方式来进行传递，这种情况下，一个攻击者必须完成必要的3步来劫持用户的session:获取一个合法的session ID在请求中加入相同的User-Agent头部,用与生成token在请求中携带被攻击者的token这里面有个问题。如果session id以及token都是通过GET数据来传递的话，那么对于能获取session ID的攻击者，同样就能够获取到这个token。所以，比较安全靠谱的方式应该是利用两种不同的数据传递方式来分别传递session id以及token。例如，通过cookie来传递session id,然后通过GET数据来传递token。因此，假如攻击者通过某种手段获得了这个唯一的用户身份标识，也是不太可能同时轻松地获取到这个token，它相对来说依然是安全的。还有很多的技术手段可以用来加强你的session机制的安全性。希望你在大致了解session的内部本质以后，可以设计出适合你的应用系统的验证机制，从而大大的提高系统的安全性。毕竟，你是最熟悉当下你开发的系统的开发者之一，可以根据实际情况来实施一些特有的，额外的安全措施。总结以上只是大概地描述了session的工作机制，以及简单地阐述了一些安全措施。但要记住，以上的方法都是能够加强安全性，不是说能够完全保护你的系统，希望读者自己再去调研相关内容。在这个调研过程中，相信你会学到很有实际使用价值的方案。

关于session和memcache的若干问题 关于session和memcache的若干问题一直以来,由于php本身的session机制不能跨机,令很多phper感到不爽,现在流行的解决方案主要有:1)使用数据库来实现2)自己写server端,通过改写session处理函数来请求3)使用nfs等跨机存储来保存session4)使用memcache来保存5)使用zend platform提供的解决方案其中的1-4都是通过改用可以跨机的储存机制,再使用session_set_save_handler()来实现,5是zend公司的商业产品(不过据之前在使用的同事反映,效果不太满意),以上的方案,各有利弊,不在本文讨论范围无论是用memcache,还是db,nfs,其原理是一样的,都是通过session_set_save_handler函数来改变默认的处理方式,通过指定回调函数来自定义处理,可以参考手册的session_set_save_handler()函数部分,有例子,比较容易明白以下是一些我在使用memcache来实现时的一些记录:1)使用类来实现时,各回调函数都定义为静态方法,在类的构造中使用session_set_save_handler注册回调函数, 如:session_set_save_handler(array(\'memSession\', \'open\'),array(\'memSession\', \'close\'),array(\'memSession\', \'read\'),array(\'memSession\', \'write\'),array(\'memSession\', \'destroy\'),array(\'memSession\', \'gc\'));memSession为类名,要使用session,则先new memSession,再session_start();2)生存期和垃圾回收memCache的set命令有生存期,即使用set命令添加值时,可加上lifetime,此时间可以作为session的生存期,用户在此时间内没有动作,则会失效,但有动作则不会失效(因为每一个脚本结束时,都会执行write和close,此时lifetime就会被更新了),当然,如果使用cookie传递SID,则控制SESSION生存期可以用:ini_set(\'session.cookie_lifetime\',time)来设定,这其实是控制cookie的有效时间,如果session赖以生存的cookie消失了,当然session也就活不了,使用cookie_lifetime来控制的话,无论有无动作,都将在指定的时间后过时gc是指垃圾回收,在session中是指清理过期的session数据,影响的参数有:session.gc_maxlifetime 被视为垃圾前的生存期,超过此时间没有动作,数据会被清走注意的是,gc不是每次启动会话都会被执行,而是由session.gc_probability 和 session.gc_divisor的比率决定的结论:控制SESSION的生存期有几种方法一是cookie_lifttime,这种方式无论有无动作,都会在指定时间内销毁二是在read中根椐保存时间控制,此方法在有动作时时间会一直有效三设定session.gc_probability 和 session.gc_divisor的比率为1(即每次会话都会启用gc),再设定gc.maxlifetime来指定生存期,此方法也是在用户有动作时时间一直有效3)回调函数的执行时机open 在运行session_start()时执行read 在运行session_start()时执行,因为在session_start时,会去read当前session数据并写入$_SESSION变量destroy 在运行session_destroy()时执行close 在脚本执行完成或调用session_write_close() 或 session_destroy()时被执行,即在所有session操作完成后被执行gc 执行概率由session.gc_probability 和 session.gc_divisor的值决定,时机是在open,read之后,即session_start会相继执行open,read和gcwrite 此方法在脚本结束和使用session_write_close()强制提交SESSION数据时执行结论:session_start //执行open(启动会话),read(读取session数据至$_SESSION),gc(清理垃圾)脚本中间所有对$_SESSION的操作均不会调用这些回调函数session_destroy //执行destroy,销毁当前session(一般是删除相应的记录或文件),相应地,此回调函数销毁的只是session的数据,但此时var_dump一下$_SESSION变量,仍然有值的,但此值不会在close后被write回去session_write_close() //执行write和close,保存$_SESSION至存储,如不手工使用此方法,则会在脚本结束时被自动执行清晰了以上信息,将对你清楚了解SESSION的工作原理有很大的帮助...4)直接使用memcache作session处理在我写了一系列的memcache来保存session的代码后,无意中发现,可以直接在php.ini中设定使用memcache作为session处理,而无须另外编码,方法是:修改php.ini中的以下值session.save_handler = memcachesession.save_path = \'tcp://host1:11211\' #有多个时直接用","分隔即可如果只想在特定的应用里使用memcache储存session,可以使用ini_set的方法对以上两个参数进行设定要测试一下是否真正用上了memcache,可以先捕足到使用的PHPSESSID,再作为KEY用memcach去读一下,就清楚了

如何设置一个严格30分钟过期的Session 如何设置一个严格30分钟过期的Session我在面试的时候, 经常会问一个问题: "如何设置一个30分钟过期的Session?", 大家不要觉得看似简单, 这里面包含的知识挺多, 特别适合考察基本功是否扎实, 谁来回答试试? 呵呵为什么问这个问题呢? 1. 我在Twitter上看到了有人讨论这个问题, 2 想起来我经常问这个问题, 所以~~在这里, 我来解答下这个题目.第一种回答那么, 最常见的一种回答是: 设置Session的过期时间, 也就是session.gc_maxlifetime, 这种回答是不正确的, 原因如下:首先, 这个PHP是用一定的概率来运行session的gc的, 也就是session.gc_probability和session.gc_divisor(介绍参看 深入理解PHP原理之Session Gc的一个小概率Notice), 这个默认的值分别是1和100, 也就是有1%的机会, PHP会在一个Session启动时, 运行Session gc. 不能保证到30分钟的时候一定会过期.那设置一个大概率的清理机会呢? 还是不妥, 为什么? 因为PHP使用stat Session文件的修改时间来判断是否过期, 如果增大这个概率一来会降低性能, 二来, PHP使用"一个"文件来保存和一个会话相关的Session变量, 假设我5分钟前设置了一个a=1的Session变量, 5分钟后又设置了一个b=2的Seesion变量, 那么这个Session文件的修改时间为添加b时刻的时间, 那么a就不能在30分钟的时候, 被清理了. 另外还有下面第三个原因.PHP默认的(Linux为例), 是使用/tmp 作为Session的默认存储目录, 并且手册中也有如下的描述:Note: 如果不同的脚本具有不同的 session.gc_maxlifetime 数值但是共享了同一个地方存储会话数据，则具有最小数值的脚本会清理数据。此情况下，与 session.save_path 一起使用本指令。也就是说, 如果有俩个应用都没有指定自己独立的save_path, 一个设置了过期时间为2分钟(假设为A), 一个设置为30分钟(假设为B), 那么每次当A的Session gc运行的时候, 就会同时删除属于应用B的Session files.所以, 第一种答案是不"完全严格"正确的.第二种答案还有一种常见的答案是: 设置Session ID的载体, Cookie的过期时间, 也就是session.cookie_lifetime. 这种回答也是不正确的, 原因如下:这个过期只是Cookie过期, 换个说法这点就考察Cookie和Session的区别, Session过期是服务器过期, 而Cookie过期是客户端(浏览器)来保证的, 即使你设置了Cookie过期, 这个只能保证标准浏览器到期的时候, 不会发送这个Cookie(包含着Session ID), 而如果通过构造请求, 还是可以使用这个Session ID的值.第三种答案使用memcache, redis等, okey, 这种答案是一种正确答案. 不过, 很显然出题者肯定还会接着问你, 如果只是使用PHP呢?第四种答案当然, 面试不是为了难道你, 而是为了考察思考的周密性. 在这个过程中我会提示出这些陷阱, 所以一般来说, 符合题意的做法是:设置Cookie过期时间30分钟, 并设置Session的lifetime也为30分钟.自己为每一个Session值增加Time stamp.每次访问之前, 判断时间戳.最后, 有同学问, 为什么要设置30分钟的过期时间: 这个, 首先这是为了面试, 第二, 实际使用场景的话, 比如30分钟就过期的优惠劵?