㈠ 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的生成演算法是唯一的嗎
雖然他的那個生成演算法是隨機的，但是是唯一的。