由於部門網站僅供內部使用，而我們面對的客戶又是國際大廠。所以，大家在上面所討論的東西或者資訊，不可避免地會觸及客戶資料。為了安全起見，整個網站使用 HTTPS 是必要的作法，直接把所有 HTTP request 用 Rewrite 轉給 HTTPS。
除了將 anonymous user 取消所有權限外，另外也啟用 Secure Site 模組，加上使用瀏覽器輸入帳號密碼的 Basic Authentication 方式。
不過這模組有個小 bug，啟用之後會影響到 cron 的執行。仔細觀察 securesite.module 後發現，它其實有處理 cron bypass。那…為什麼會有問題？因為我在 setting.php 裡面對 $base_url 做了設定，結果就產生錯誤。
回頭去翻 CVS messages，又發現舊的方法反而比較對：
// bypass cron.php
if (!$securesite_enabled || strstr(request_uri(),'cron.php')) {
return;
}
於是手動改掉，並且回報給開發人員，靜待回音。
更新：
又重新思考一下為什麼開發者會放掉這個方式？很簡單，若是有人使用 http://example.com:88/drupal/whatever?cron.php 類似的 URL 就可以通過該檢查。那，我們從 $base_url 下手如何？
// bypass cron.php
$cron_uri = preg_replace('/^(http|https):\/\/[\d\w.:-]*/i','',$base_url.'/cron.php');
if (!$securesite_enabled || request_uri() == $cron_uri) {
return;
}
改成這樣，就可以取得 $cron_uri 啦！不知道對不對齁？
更新：
不知道為什麼 mail new password 的功能有問題，造成新密碼無法使用，只好將它停用。