最近把 DNS 轉到 Cloudflare 使用, 原本在主機上使用 HAProxy 把 SSL 的封包轉到個別對應的軟體是使用 Proxy Protocol 將來源 IP 通知處理的軟體. 在改用 Cloudflare 之後, 這個 IP 就變成 Cloudflare 的 IP 了. 這個在需要知道來源 IP 的軟體上, 就反而造成問題. (閱讀全文)
以往 SSL 憑證都要花錢買, 當然... 也可以自己用 openssl 來產生, 不過.... 自己做的 rootca 並不會被其他人承認, 常常要自己匯入後才能正常使用. 不過... 這情形在 Let's Encrypt 出現後, 大家都可以申請免費的 SSL 憑證了, 雖然期限只有三個月, 不過.... 只要到期前記得去 renew 就可以一直用下去. (閱讀全文)
在一般靜態網頁的處理上頭, nginx 可以正常的顯示一些錯誤的訊息 (如 404 File not found 之類的訊息). 不過對於 PHP (其他用 fastcgi 方式跑的程式也一樣), 預設來說, 如果有什麼錯誤, 往往就看到空白的一個網頁. 而一般的 nginx 教學上頭, 對於這個問題的處理建議就是 fastcgi_intercept_errors on 的設定. 但... 這個方式並不是完美的. (閱讀全文)
這幾天在測試 Gallery3, 測試 Gallery Remote 時, 發現原本裝的 Gallery2 在使用 Gallery Remote 時也無法正常登入. 登入時會出現這個錯誤訊息:
這錯誤在 Gallery Remote 的 FAQ 裡頭就有, 應該是一開始執行是會去使用 gallery_remote2.php, 如果不存在, 才會轉用別的 URL, 而在 Gallery2 的時候, 是沒有 gallery_remote2.php 的, 正常來說, 這個存取會回傳 404 not found 的錯誤, 不過... 由於我的 nginx 有對 404 做轉向的處理, 結果... 會造成實際收到的是 302 的轉向回應, 所以... 接下去就動作就不正常了.
原本希望保留我在 nginx 下的轉向設定, 只針對 gallery_remote2.php 回應 404 就可以. 不過... 試了一下, 發現似乎不能這樣子處理, 因為只要有轉向的設定, 不過是透過 php 去回應 404, 或在 nginx 對該 URL 回應 404, 都還是會去做轉向的動作.
最後... 只好在使用 Gallery2 的這個 virtual host 中不去對 404 做轉向處理, 改成回應 404 的錯誤. 如:
error_page 404 /internal_error_404_page.html;
location /internal_error_404_page.html {
internal;
}
這樣子改之後, 就可以正常登入了.