㈠ php输出服务器上所有的session或sessionid
可以理解成每一个sessionid是一个文件，输出所有的sessionid可以理解成读出所有的session文件。文件的目录在apache里的session_dir选项可以获得。
㈡ PHP的用于用户验证的session id有几种生成方法
貌似只有自动生成的一种 ...
编写代码生成的和浏览器不绑定 ...
㈢ PHP使用cookie,session和SQL写登陆页面
session是由应用服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的sessionid,用该sessionid
为标识符来存取服务器端的session存储空间。而sessionid这一数据则是保存到客户端，用cookie保存的，用户提交页面时，会将这一
sessionid提交到服务器端，来存取session数据。这一过程，是不用开发人员干预的。所以一旦客户端禁用cookie，那么session也会失效。
服务器也可以通过url重写的方式来传递sessionid的值，因此不是完全依赖cookie。如果客户端cookie禁用，则服务器可以自动通过重写url的方式来保存session的值，并且这个过程对程序员透明。
可以试一下，即使不写cookie，在使用request.getcookies();取出的cookie数组的长度也是1，而这个cookie的名字就是jsessionid，还有一个很长的二进制的字符串，是sessionid的值。
cookie是客户端的存储空间，由浏览器来维持。
㈣ PHP中SESSION的问题
Session 和 Cookie 有什么关系
Cookie 也是由于 HTTP 无状态的特点而产生的技术。也被用于保存访问者的身份标示和一些数据。每次客户端发起 HTTP 请求时，会将 Cookie 数据加到 HTTP header 中，提交给服务端。这样服务端就可以根据 Cookie 的内容知道访问者的信息了。 可以说，Session 和 Cookie 做着相似的事情，只是 Session 是将数据保存在服务端，通过客户端提交来的 session_id 来获取对应的数据；而 Cookie 是将数据保存在客户端，每次发起请求时将数据提交给服务端的。
上面提到，session_id 可以通过 URL 或 cookie 来传递，由于 URL 的方式比 cookie 的方式更加不安全且使用不方便，所以一般是采用 cookie 来传递 session_id。
服务端生成 session_id，通过 HTTP 报文发送给客户端（比如浏览器），客户端收到后按指示创建保存着 session_id 的 cookie。cookie 是以 key/value 形式保存的，看上去大概就这个样子的：PHPSESSID=e4tqo2ajfbqqia9prm8t83b1f2。在 PHP 中，保存 session_id 的 cookie 名称默认叫作 PHPSESSID，这个名称可以通过 php.ini 中 session.name 来修改，也可以通过函数 session_name() 来修改。
为什么不推荐使用 PHP 自带的 files 型 Session 处理器
在 PHP 中，默认的 Session 处理器是 files，处理器可以用户自己实现（参见：自定义会话管理器）。我知道的成熟的 Session 处理器还有很多：Redis、Memcached、MongoDB……
为什么不推荐使用 PHP 自带的 files 类型处理器，PHP 官方手册中给出过这样一段 Note：
无论是通过调用函数 session_start() 手动开启会话， 还是使用配置项 session.auto_start 自动开启会话， 对于基于文件的会话数据保存（PHP 的默认行为）而言， 在会话开始的时候都会给会话数据文件加锁， 直到 PHP 脚本执行完毕或者显式调用 session_write_close() 来保存会话数据。 在此期间，其他脚本不可以访问同一个会话数据文件。
上述引用参见：Session 的基本用法
为了证明这段话，我们创建一下 2 个文件： 文件：session1.php
<?php
session_start();
sleep(5);
var_mp($_SESSION);
?>
文件：session2.php
<?php
session_start();
var_mp($_SESSION);
?>
在同一个浏览器中，先访问 http://127.0.0.1/session1.php，然后在当前浏览器新的标签页立刻访问 http://127.0.0.1/session2.php。实验发现，session1.php 等了 5 秒钟才有输出，而 session2.php 也等到了将近 5 秒才有输出。而单独访问 session2.php 是秒开的。在一个浏览器中访问 session1.php，然后立刻在另外一个浏览器中访问 session2.php。结果是 session1.php 等待 5 秒钟有输出，而 session2.php 是秒开的。
分析一下造成这个现象的原因：上面例子中，默认使用 Cookie 来传递 session_id，而且 Cookie 的作用域是相同。这样，在同一个浏览器中访问这 2 个地址，提交给服务器的 session_id 就是相同的（这样才能标记访问者，这是我们期望的效果）。当访问 session1.php 时，PHP 根据提交的 session_id，在服务器保存 Session 文件的路径（默认为 /tmp，通过 php.ini 中的 session.save_path 或者函数 session_save_path() 来修改）中找到了对应的 Session 文件，并对其加锁。如果不显式调用 session_write_close()，那么直到当前 PHP 脚本执行完毕才会释放文件锁。如果在脚本中有比较耗时的操作（比如例子中的 sleep(5)），那么另一个持有相同 session_id 的请求由于文件被锁，所以只能被迫等待，于是就发生了请求阻塞的情况。
既然如此，在使用完 Session 后，立刻显示调用 session_write_close() 是不是就解决问题了哩？比如上面例子中，在 sleep(5) 前面调用 session_write_close()。
确实，这样 session2.php 就不会被 session1.php 所阻塞。但是，显示调用了 session_write_close() 就意味着将数据写到文件中并结束当前会话。那么，在后面代码中要使用 Session 时，必须重新调用 session_start()。
例如：
<?php
session_start();
$_SESSION['name'] = 'Jing';
var_mp($_SESSION);
session_write_close();
sleep(5);
session_start();
$_SESSION['name'] = 'Mr.Jing';
var_mp($_SESSION);
?>
官方给出的方案：
对于大量使用 Ajax 或者并发请求的网站而言，这可能是一个严重的问题。 解决这个问题最简单的做法是如果修改了会话中的变量， 那么应该尽快调用 session_write_close() 来保存会话数据并释放文件锁。 还有一种选择就是使用支持并发操作的会话保存管理器来替代文件会话保存管理器。
我推荐的方式是使用 Redis 作为 Session 的处理器。
拓展阅读：
为什么不能用 memcached 存储 Session
如何使用 Redis 作为 PHP Session handler
Session 数据是什么时候被删除的
这是一道经常被面试官问起的问题。
先看看官方手册中的说明：
session.gc_maxlifetime 指定过了多少秒之后数据就会被视为"垃圾"并被清除。 垃圾搜集可能会在 session 启动的时候开始（ 取决于 session.gc_probability 和 session.gc_divisor）。 session.gc_probability 与 session.gc_divisor 合起来用来管理 gc（garbage collection 垃圾回收）进程启动的概率。此概率用 gc_probability/gc_divisor 计算得来。例如 1/100 意味着在每个请求中有 1% 的概率启动 gc 进程。session.gc_probability 默认为 1，session.gc_divisor 默认为 100。
继续用我上面那个不太恰当的比方吧：如果我们把物品放在超市的储物箱中而不取走，过了很久（比如一个月），那么保安就要清理这些储物箱中的物品了。当然并不是超过期限了保安就一定会来清理，也许他懒，又或者他压根就没有想起来这件事情。
再看看两段手册的引用：
如果使用默认的基于文件的会话处理器，则文件系统必须保持跟踪访问时间（atime）。Windows FAT 文件系统不行，因此如果必须使用 FAT 文件系统或者其他不能跟踪 atime 的文件系统，那就不得不想别的办法来处理会话数据的垃圾回收。自 PHP 4.2.3 起用 mtime（修改时间）来代替了 atime。因此对于不能跟踪 atime 的文件系统也没问题了。
GC 的运行时机并不是精准的，带有一定的或然性，所以这个设置项并不能确保旧的会话数据被删除。某些会话存储处理模块不使用此设置项。
对于这种删除机制，我是存疑的。
比如 gc_probability/gc_divisor 设置得比较大，或者网站的请求量比较大，那么 GC 进程启动就会比较频繁。
还有，GC 进程启动后都需要遍历 Session 文件列表，对比文件的修改时间和服务端的当前时间，判断文件是否过期而决定是否删除文件。
这也是我觉得不应该使用 PHP 自带的 files 型 Session 处理器的原因。而 Redis 或 Memcached 天生就支持 key/value 过期机制的，用于作为会话处理器很合适。或者自己实现一个基于文件的处理器，当根据 session_id 获取对应的单个 Session 文件时判断文件是否过期。
为什么重启浏览器后 Session 数据就取不到了
session.cookie_lifetime 以秒数指定了发送到浏览器的 cookie 的生命周期。值为 0 表示"直到关闭浏览器"。默认为 0。
其实，并不是 Session 数据被删除（也有可能是，概率比较小，参见上一节）。只是关闭浏览器时，保存 session_id 的 Cookie 没有了。也就是你弄丢了打开超市储物箱的钥匙（session_id）。
同理，浏览器 Cookie 被手动清除或者其他软件清除也会造成这个结果。
为什么浏览器开着，我很久没有操作就被登出了
这个是称为“防呆”，为了保护用户账户安全的。
这个小节放进来，是因为这个功能的实现可能和 Session 的删除机制有关（之所以说是可能，是因为这个功能不一定要借住 Session 实现，用 Cookie 也同样可以实现）。 说简单一点，就是长时间没有操作，服务端的 Session 文件过期被删除了。
一个有意思的事情
在我试验的过程中，发现了小有意思的事情：我把 GC 启动的概率设置为 100%。如果只有一个访问者请求，该访问者即使过了很久（超过了过期时间）后才发起第二次请求，那么 Session 数据也还是存在的（'session.save_path' 目录下面的 Session 文件存在）。是的，明明就超过了过期时间，却没有被 GC 删除。这时，我用另外一个浏览器访问时（相对于另一个访问者），这次请求生成了新的 Session 文件，而上一个浏览器请求生成的那个 Session 文件终于没有了（之前那个 Session 文件在 'session.save_path' 目录下面的消失了）。
还有，发现 Session 文件被删除后，再次请求，还是会生成和之前文件名相同的 Session 文件（因为浏览器并没有关闭，再次请求发送的 session_id 是相同的，所以重新生成的 Session 文件的文件名还是一样的）。但是，我不理解的是：这个重新出现的文件的创建时间竟然是第一次的那个创建时间，难道它是从回收站中回来的？（确实，我做这个试验时是在 window 下进行的）
我猜测的原因是这样：当启动会话后，PHP 根据 session_id 找到并打开了对应的 Session 文件，然后才启动 GC 进程。GC 进程就只检查除了当前这个 Session 文件外的其他文件，发现过期的就干掉。所有，即使当前这个 Session 文件已经过期了，GC 也没有删除它。
我认为这个不合理的。
由于发生这种情况影响也不大（毕竟线上请求很多，当前请求的过期文件被其他请求唤起的 GC 干掉的可能性是比较大的） + 我没有信心去看 PHP 源代码 + 我并不在线上使用 PHP 自带的 files 型 Session 处理器。所以，这个问题我就没有深入研究了。请谅解。
<?php
// 过期时间设置为 30 秒
ini_set('session.gc_maxlifetime', '30');
// GC 启动概率设置为 100%
ini_set('session.gc_probability', '100');
ini_set('session.gc_divisor', '100');
session_start();
$_SESSION['name'] = 'Jing';
var_mp($_SESSION);
?>
㈤ 用PHP怎么在session里存多个id
这个你不用担心，每个session都有唯一的session_id，每次生成session，php都会自动生成1条唯一的session
session_id是不会打印出来的
只能另行输出 echo session_id()
或者可以：
Session 的工作机制是：为每个访问者创建一个唯一的 id (UID)，并基于这个 UID 来存储变量。UID 存储在 cookie 中，亦或通过 URL 进行传导。
前序：
首先要明白PHPSESSID看似多次刷新都不会改变其实是没有删除本地相关联的cookie，删除的方法
session_destroy();//删除服务器端的session文件
setcookie(session_name(),'',time()-3600,'/');//删除本地相关联的cookie
session_unset();//清空内存中的cookie或者是$_SESSION = array();
然后再刷新相应的页面你就会看到PHPSESSID会发生变化了，根据此可以得：如果session文件已经创建则不重新生成PHPSESSID,否则需要重新生成，生成规则，就看下边喽……！
--------------------------------------------------------------------------------------------------------------------------------------
现在经过测试应该是不是检测session文件是否存在，而是检测PHPSESSID的cookie是否存在并且是否未过期！特此更正！
------------------------------------------------------------------------------------------------
可能PHP开发者心中多少都思考过这么两个问题：
种植在客户端浏览器中的PHPSESSIONID会出现重复吗？
PHPSESSIONID安全性如何，有没可能被黑客轻易的仿造呢？
带上这个问题，我稍微注意了一下PHP的源码后，疑问也就有了答案。
PHP在使用默认的 session.save_handler = files 方式时，PHPSESSIONID的生产算法原理如下：
hash_func = md5 / sha1 #可由php.ini配置
PHPSESSIONID = hash_func(客户端IP + 当前时间（秒）+ 当前时间（微妙）+ PHP自带的随机数生产器)
从以上hash_func(*)中的数据采样值的内容分析，多个用户在同一台服务器时所生产的PHPSESSIONID重复的概率极低（至少为百万份之一），设想，但台动态Web Server能到2000/rps已经很强悍了。
另外，黑客如果要猜出某一用户的PHPSESSIONID，则他也必须知道“客户端IP、当前时间（秒、微妙）、随机数”等数据方可模拟。
以下是截取PHP源码中PHPSESSIONID实现片段：
gettimeofday(&tv, NULL);
if (
zend_hash_find(&EG(symbol_table), "_SERVER", sizeof("_SERVER"), (void **) &array) == SUCCESS &&
Z_TYPE_PP(array) == IS_ARRAY && zend_hash_find(Z_ARRVAL_PP(array), "REMOTE_ADDR", sizeof("REMOTE_ADDR"), (void **) &token) == SUCCESS)
{
remote_addr = Z_STRVAL_PP(token);
}
spprintf(&buf, 0, "%.15s%ld%ld%0.8F", remote_addr ? remote_addr : "", tv.tv_sec, (long int)tv.tv_usec, php_combined_lcg(TSRMLS_C) * 10);
switch (PS(hash_func))
{
case PS_HASH_FUNC_MD5:
PHP_MD5Init(&md5_context);
PHP_MD5Update(&md5_context, (unsigned char *) buf, strlen(buf));
digest_len = 16;
break;
case PS_HASH_FUNC_SHA1:
PHP_SHA1Init(&sha1_context);
PHP_SHA1Update(&sha1_context, (unsigned char *) buf, strlen(buf));
digest_len = 20;
break;
default:
php_error_docref(NULL TSRMLS_CC, E_ERROR, "Invalid session hash function");
efree(buf);
return NULL;
}
㈥ php网站的session 在服务器端是如何给客户端分配sessionid的
在PHP.INI里面有一项session.save_path，就是设置session保存位置的。
session是通过cookie来实现的，当浏览器访问一个页面时，php发现在cookie里面没有sessionid这个值，就会产生一个sessionid出来，同时对应一个服务器里面的session文件。然后通过cookie传给浏览器（通过cookie），下次浏览器再访问页面的时候，就会把这个sessionid给带上（也是cookie），然后php通过这个cookie找到对应的session文件，读取session的值。
也就是说如果用户关了cookie那session就用不了了。
以上就是session的原理，不过一般来说你也不需要了解它。
㈦ php中的sessionId是干什么的
SESSION_ID会话ID。
session_data是编码会话数据。这个数据是在PHP内部编码$_SESSION超全局，以序列化字符串，并把它当作这个参数的结果。
请注意会话使用替代序列化方法。
返回值
会话存储的返回值（通常成功返回 0，失败返回 1）。
㈧ php登录后生成session怎么弄
登陆页index.php
<?PHP
if(isset($_POST['submit'])&&isset($_POST['submit'])=='确定')
{
if($_POST['user']=='user'&&$_POST['pwd']=='pwd')
{
session_start();//打开session
$_SESSION["user"]=$_POST['user'];//新建一个session
echo'登陆成功';
}
else
echo'用户名或密码错误！';
}
else
{
echo'<formact=""method="post">';
echo'用户名：<inputname="user"type="text"/>';
echo'密码：<inputname="pwd"type="password"/>';
echo'<inputtype="submit"name="submit"value="确定"/>';
echo'</form>';
}
?>
判断是否登陆页add.php
<?php
session_start();
if($_SESSION["user"]==null)
{
echo"请登陆";
echo"<script>location.href='index.php';</SCRIPT>";
returnfalse;
}
else
{
echo"以登陆";
echo"<ahref='esc.php'>点击退出</a>";
}
?>
退出页esc.php
<?php
session_start();
session_destroy();
echo"<script>alert('退出成功！');this.location.href='index.php';</SCRIPT>";
?>
㈨ PHP中Session ID的生成算法是唯一的吗
虽然他的那个生成算法是随机的，但是是唯一的。