CAS 是目前比較流行的單點登入協定,官方提供了 php 版本的 client 端 phpCAS,到目前為止其編碼風格還一直停留在 PEAR 時代,連名稱空間都沒有使用。好在 phpCAS 支援 composer 引入,做過幾個 Laravel 專案引入也沒有什麼問題,然而這兩天有一個專案需要從單機部署變成多機部署,萬萬沒想到在這裡踩了一些坑,在此記錄一下。
回撥坑
在跳轉到 CAS Server 進行認證時發現,傳入的回撥地址被加上了埠8080。因為是多機部署,所以存取請求會先經過負載均衡器(阿里雲 SLB),再到達 web 伺服器,而這個8080是 web 伺服器的監聽埠。
於是追查 phpCAS 生成回撥地址的邏輯,發現有這麼一段程式碼:
if (empty($_SERVER['HTTP_X_FORWARDED_PORT'])) { $server_port = $_SERVER['SERVER_PORT']; } else { $ports = explode(',', $_SERVER['HTTP_X_FORWARDED_PORT']); $server_port = $ports[0]; }
而阿里雲的 SLB 並不會傳給後端伺服器 X-FORWARDED-PORT
這個 http 頭,因此 phpCAS 就會拿到 $_SERVER['SERVER_PORT']
也就是 nginx 的埠8080。
好在 phpCAS 提供了 setFixedServiceURL
函數,可以讓我們手動去設定回撥地址:
phpCAS::setFixedServiceURL($request->url());
這下回撥地址正常了,但是從 CAS Server 返回到 client 端時被告知 ticket 無效。
繼續查紀錄檔和程式碼,發現這裡是自己疏忽了,當 CAS Server 返回到 client 端時頁面的 url 是 http://client/login?ticket=xxxxx
,而 client 端使用 ticket 向 server 換取使用者資訊時還需要帶上申請該 ticket 時的回撥地址(service),server 端會校驗 ticket 和 service 是否一致,而申請 ticket 時的 service 應該是 http://client/login
,因此我們需要把 url 裡的 ticket 引數去掉。
phpCAS::setFixedServiceURL($this->getUrlWithoutTicket($request));
getUrlWithoutTicket
函數如下:
private function getUrlWithoutTicket(Request $request) { $query = parse_query($request->getQueryString()); unset($query['ticket']); $question = $request->getBaseUrl().$request->getPathInfo() == '/' ? '/?' : '?'; return $query ? $request->url().$question.http_build_query($query) : $request->url(); }
Session 坑
這是一個 phpCAS + Laravel 的組合坑,坑得死去活來沒脾氣。
PHP 預設是 Session 儲存方式是檔案,因此單機變多機一個很重要的點就是處理 Session 共用。方案也很簡單,就是把 Session 儲存方式從檔案改成 redis/memecache/database 等。
Laravel 預設提供了這些 driver,於是興沖沖地改了下 .env
檔案,把 SESSION_DRIVER
改成 redis
。拉到線上一試,發現不行,phpCAS 對 $_SESSION
變數的變更並沒有被寫到 redis 裡,怎麼回事!
於是追了一下 Laravel 的 Session 實現,發現並不是想象中的使用 session_set_save_handler
來註冊 Session 讀寫邏輯,也就是說 Laravel 的 Session 其實並沒有修改 php 的 $_SESSION
的讀寫邏輯,直接操作 $_SESSION
還是走的預設行為(讀寫本地檔案)。
那好吧,好在 Laravel 的幾個 SessionDriver 都實現了 SessionHandlerInterface
介面,我們可以自己呼叫一下 session_set_save_handler
:
session_set_save_handler(app(StartSession::class)->getSession($request)->getHandler());
萬萬沒想到報錯!
session_write_close(): Session callback expects true/false return value
追了一下 Laravel 的程式碼,發現 redis driver 的父類別 Illuminate\Session\CacheBasedSessionHandler
的 write
方法返回的是 void
。於是提了一個 PR 打算修一下,沒想到被拒絕,原來是之前有人修過又被 revert 了,說是會導致伺服器卡住,然而我並沒有找到具體的 issue。
那好吧,memcache 和 redis 都是繼承的這個父類別,那我就換隻好 database 試試看。
這回 session_write_close
不報錯了,但是 CAS 登入還是有問題,不斷在 CAS server 和回撥 url 之間跳轉。於是又追了一路 log 和程式碼,發現 database driver 類 Illuminate\Session\DatabaseSessionHandler
的 destroy
方法在銷燬 Session 之後沒有將 $this->exists
屬性標記為 false
,而 phpCAS 有一處邏輯是 renameSession
$old_session = $_SESSION; session_destroy(); $session_id = preg_replace('/[^a-zA-Z0-9\-]/', '', $ticket); session_id($session_id); session_start(); $_SESSION = $old_session;
後果就是 $_SESSION = $old_session;
所對應操作 session 表的 sql 執行的是 update 而不是 insert,也就是沒能將 session 資料寫入 session 表!
實在沒有辦法了,只能自己寫一個 Session Wrapper 來處理。
從上面兩個情況來看,redis driver 比較好處理,只要能在呼叫 write 方法時返回 true 就可以了。所以程式碼如下
namespace App\Services; use SessionHandlerInterface; class MySession implements SessionHandlerInterface { /** * @var SessionHandlerInterface */ protected $realHdl; /** * Session constructor. * @param SessionHandlerInterface $realHdl */ public function __construct(SessionHandlerInterface $realHdl) { $this->realHdl = $realHdl; } public function close() { return $this->realHdl->close(); } public function destroy($session_id) { return $this->realHdl->destroy($session_id); } public function gc($maxlifetime) { return $this->realHdl->gc($maxlifetime); } public function open($save_path, $name) { return $this->realHdl->open($save_path, $name); } public function read($session_id) { return $this->realHdl->read($session_id) ?: ''; } public function write($session_id, $session_data) { $this->realHdl->write($session_id, $session_data); return true; // 這裡 } }
然後呼叫 session_set_save_handler
變成
session_set_save_handler(new MySession(app(StartSession::class)->getSession($request)->getHandler()));
Done !