Category: Web Developer

Posted on by

wordpress 永久連結設定失效

故障的可能原因

  1. .htaccess 檔案不正常：進入 WordPress 的管理後台，點擊「設定」→「連結」，然後按下「儲存變更」。這樣 WordPress 會重新生成 .htaccess 檔案。如果這個步驟沒有解決問題，可以手動在 WordPress 安裝目錄中找到 .htaccess 檔案，並且檢查它是否存在。
  2. 確認 WordPress 是否在正確的網址上運行：如果您的 WordPress 安裝在子目錄或子網域下，請確認永久連結設定正確設定到子目錄下這一點。
  3. 伺服器是否支援永久連結：如果您的伺服器不支援永久連結，則 WordPress 將無法使用它們。(設定方式請見下一篇)
  4. 確認您的主題是否有任何問題：某些 WordPress 主題可能會干擾永久連結的正常運作。嘗試暫時更換到 WordPress 默認主題並再次測試永久連結。

在Apache2支持永久連結

要啟用 Apache2 的 mod_rewrite 模組，您需要將以下內容添加到 Apache2 的設定檔案中：

LoadModule rewrite_module modules/mod_rewrite.so

這個設定通常會加入到 mods-enabled 目錄中的一個設定檔案中。例如，您可以創建一個名為 rewrite.load 的檔案，並將上面的設定添加到這個檔案中。請按照以下步驟進行操作：

  1. 進入 mods-enabled 目錄：
cd /etc/apache2/mods-available
  1. 創建一個名為 rewrite.load 的檔案：
sudo touch rewrite.load
  1. 打開這個檔案並添加以下內容：
LoadModule rewrite_module modules/mod_rewrite.so
  1. 儲存並關閉檔案。
  2. 重新啟動 Apache2 伺服器，以使更改生效：
sudo service apache2 restart

啟用rewrite功能

若您的 /etc/apache2/mods-available 目錄下已經有了 rewrite.load 設定檔案，您可以透過建立符號連結方式來啟用 mod_rewrite 模組。

請按照以下步驟：

  1. 進入到 /etc/apache2/mods-enabled 目錄：
cd /etc/apache2/mods-enabled
  1. 建立 rewrite.load 的符號連結：
sudo ln -s /etc/apache2/mods-available/rewrite.load
  1. 重新啟動 Apache2 伺服器，以使更改生效：
sudo service apache2 restart

執行完上述步驟後，Apache2 的 mod_rewrite 模組即會啟用。您可以再次檢查 /etc/apache2/mods-enabled 目錄，確保 rewrite.load 的符號連結已經建立。若您需要停用 mod_rewrite，則可以刪除這個符號連結即可。

Posted on by

在AWS的EC2裡加上SSL/TSL

SSL/TSL是甚麼

SSL/TLS是一種網絡協議，用於在客戶端和服務器之間提供安全的數據傳輸。 SSL代表“安全套接字層”，TLS代表“傳輸層安全性”，兩者是相似的協議，TLS是SSL的升級版。

SSL/TLS通過加密數據流來保護通信的隱私和完整性，以防止數據在傳輸過程中被竊聽或篡改。它使用數字證書來驗證服務器身份，以確保連接到的服務器是預期的服務器，而不是惡意者偽裝的服務器。

SSL/TLS廣泛用於保護網站，電子郵件，即時通訊，虛擬專用網絡（VPN）等應用程序中的數據傳輸。通過使用SSL/TLS，這些應用程序能夠提供更安全的通信，確保用戶的數據受到保護。

我的伺服器環境

這邊所說的是自架的Linux服務器的狀況，一般若是在網域託管的服務商買網站空間，使用cPanel等管理網站的狀況下，一般都會在空間購買裡面附設有免費的SSL/TSL證書，除非我們的網站需要額外的附加資訊才需要自行購買。

這篇文章所講的主要是當我們要在Linux裡面自行設定SSL/TSL，或使用AWS、Azure等服務的虛擬機器架設網站時，會需要自行於Linux中建立SSL/TSL並匯入所需的SSL/TSL認證。

在AWS中使用免費的ACM證書

這邊有很詳細的指導: 教學課程: 在 Amazon Linux 2 上設定 SSL/TLS

但是這邊的教程在後面匯入SSL證書的部分，是要我們自己去購買自己網域專屬的證書，那個很貴而且不太能夠免費，一般免費的SSL/TSL其組織等資訊並不會附在上面，如下圖為AWS所提供的免費證書。

要使用免費證書一個重要的前提就是要將我們所購買的網域給AWS的Route 53來託管，這個動作會產生微量的費用，一個月為0.51美金。

在AWS裡面，有一些服務本身就可以直接和Route53，若是沒辦法，則要另外建立 Elastic Load Balancing，這個是免費的，它可以用來連結我們的EC2和Route53，這樣就可以利用ACM來設定憑證了。

Posted on by

在CentOS 7的Xampp中使用Certbot

Certbot介紹

Certbot是一個由EFF（Electronic Frontier Foundation）開發的免費開源工具，用於自動化在Web服務器上部署SSL/TLS證書。它是一個自動化的客戶端，可以讓您輕鬆獲得免費的SSL/TLS證書，以保護您的網站通信，避免了手動創建證書的複雜過程。

Certbot支持多種服務器軟件，包括Apache、Nginx、HAProxy、Amazon Web Services等，它使用ACME（自動化證書管理環境）協議從Let’s Encrypt證書頒發機構獲取SSL/TLS證書。使用Certbot，您可以輕鬆地為您的網站啟用HTTPS協議，提高網站的安全性和可靠性。

如何安裝

CerBot的安裝很貼心，在官方網站就可以選擇你所使用的環境，然後他就會有很詳細的安裝教學了

官方網站: https://certbot.eff.org/

使用XAMPP的認證指令

若是要認證XAMPP的APACHE，不能直接使用–apache，而是要使用apache-ctl，如下: 

sudo certbot certonly --webroot --apache-ctl /opt/lampp/bin/apachectl

錯誤訊息除錯 – Could not find configuration root

下面這個錯誤訊息代表這個認證機器人不知道你的網站的本地端http files靜態路徑的位置

packages/certbot_apache/_internal/parser.py", line 924, in _find_config_root
    raise errors.NoInstallationError("Could not find configuration root")
certbot.errors.NoInstallationError: Could not find configuration root

解決方法: 在執行指令的時候告知http files靜態路徑的位置

sudo certbot certonly --webroot --apache-ctl /opt/lampp/bin/apachectl

錯誤訊息除錯 – Please add a virtual host for port 80

ERROR:certbot._internal.log:Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.

這個錯誤提示表明Certbot無法在端口80上找到正在偵聽的虛擬主機，以便證明您控制域名。這是因為Certbot需要在域名的80端口上創建一個臨時HTTP服務器來進行驗證，以證明您控制該域名。

要解決這個問題，您需要在Apache服務器上為端口80添加虛擬主機配置。

在/opt/lampp/apache2/conf/httpd.conf添加以下內容

<VirtualHost *:80>
    ServerAdmin your-email@example.com
    ServerName your-domain.com
    DocumentRoot /var/www/html
</VirtualHost>

接著重啟XAMPP

sudo /opt/lampp/lampp stop
sudo /opt/lampp/lampp start

其他除錯方向

  1. 防火牆沒有開：可以在本機中用curl去打IP，和從外面打，若是裡面可以外面不行，代表防火牆沒有開
  2. httpd設定只有localhost可存取: 應要把權限設定為”require all granted”。可用下面指令去搜尋電腦的httpd.conf的位置，並且尋找是不是你的網站被設定為”Require local”
sudo find / -name httpd.conf

成功拿到Certbot的SSL/TSL憑證

會可以看到下面的訊息，或許我們會懷疑為什麼都是pem，而不是.crt和.key，這是因為SSL/TLS憑證的格式可以有很多種，其中PEM格式是其中一種常見的格式，而.crt和.key則是PEM格式的一種變體。

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/bliss-angel.org/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/bliss-angel.org/privkey.pem

PEM格式是一種基於Base64編碼的標準格式，可以將數字證書和私鑰等敏感信息以文本格式表示出來，同時保持數據的可讀性。PEM格式的憑證通常以”.pem”為文件擴展名，可以包含公鑰、私鑰、憑證鏈等信息。

而.crt和.key則是PEM格式的一種變體，.crt檔案包含數字證書，.key檔案包含私鑰。這兩種檔案格式同樣是基於Base64編碼的PEM格式，只是文件名和內容有所不同。

為什麼有時候會看到PEM格式的憑證而不是.crt和.key檔案呢？這是因為PEM格式憑證可以包含多種類型的數字證書和私鑰，而且可以被用於多種網絡應用程序。例如，在OpenSSL等工具中，PEM格式憑證可以用於SSL/TLS加密、S/MIME郵件加密、SSH服務器驗證等方面。

因此，當你拿到一個PEM格式的憑證時，可以通過文件內容判斷它所包含的數字證書或私鑰類型。如果你需要將PEM格式憑證轉換成.crt和.key檔案，你可以使用OpenSSL等工具進行轉換。

但是這不影響的，仍然可以在/opt/lampp/etc/extra/httpd-ssl.conf設定，然後重啟Apache後SSL證書就生效囉!

SSLCertificateFile "/etc/letsencrypt/live/bliss-angel.org/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/bliss-angel.org/privkey.pem"
Posted on by

Socket.io錯誤訊息意義

I have found:

  • “ping timeout”: client stopped responding to pings in the allotted amount of time (per the pingTimeout config setting).
  • “transport close”: this appears to happen if the client side stopped sending data at all… or maybe there’s some kind of callback causing this to happen. I can see it happen if I just close a tab or follow a link from a page where I have an active connection to the server. But I’m not clear if this is always a case of the client causing it to happen.

    Sorry for re-opening the issue. Regarding the transport close that is the reason when page is closed/reloaded, it also happens some times in bad network conditions specifically when the ping packets are not delivered to the client. For the latter I need to handle it in the server side by waiting for the client to reconnect. Is there a way to properly distinguish between these two?

  • “Client namespace disconnect”: When the client sends a disconnect packet (client.disconnect())
  • “server namespace disconnect”: Looks to be when the server performs a socket.disconnect() action.
  • “Transport error”: An error occurred, I assume this is a server side error, but I’m not totally clear, as I’ve not been able to trigger one on my own.
  • “io server disconnect” This occurs using a third party library socketIOAuth when authentication fails

Continue reading Socket.io錯誤訊息意義

Posted on by

Socket.io介紹

Socket.io

socket.io是基於Websocket的Client-Server實時通信庫

Socket.io承繼了Node.js的事件處理方法，把Client端與Server端的程式統一成一至的操作方式，讓使用者可以只需專注在處理「事件」，就可以快速開發出應用，他也支援『房間』的概念，可以使用同一條WebSocket卻擁有不被彼此干擾的資料傳輸（多種聊天頻道的概念）。另外，他也提供了很好的fallback機制，即使用戶的瀏覽器不支援WebSocket，他還是可以利用Flash、XMLHttpRequest等方式來傳送資訊（速度會比較慢就是了）。這些機制都他都包裝好了，所以寫程式時並不需要知道這些細節，只需要設定好就可以運作。

Socket.io 特性整理

  • Events 自訂事件。
  • Rooms Room 的概念只存在於伺服器端。可以理解為訊息處理時的聽眾分組，可對同一個分組內的聽眾進行廣播。
  • Namespaces 命名空間，我理解為底層連線的分組管理，不同命名空間可以走同一條 Engine.io 連線或是各自連線，每個命名空間可以各自驗證是否接受連線。
  • ACK 回調 如同 HTTP 之於 TCP，HTTP 為 TCP 提供了一套請求與響應的模型。ACK 也為 Socket.io 提供了一套請求與響應的通訊模型。
  • 連線維護
  • 自動斷線重連
  • ping/pong 心跳

Continue reading Socket.io介紹

Posted on by

Socket.io自行增加header

伺服器端

範例程式碼:

import express from "express";
import http from "http";

const app = express();
const server = http.createServer(app);

const sio = require("socket.io")(server, {
    handlePreflightRequest: (req, res) => {
        const headers = {
            "Access-Control-Allow-Headers": "Content-Type, Authorization",
            "Access-Control-Allow-Origin": req.headers.origin, //or the specific origin you want to give access to,
            "Access-Control-Allow-Credentials": true
        };
        res.writeHead(200, headers);
        res.end();
    }
});

sio.on("connection", () => {
    console.log("Connected!");
});

server.listen(3000);

Continue reading Socket.io自行增加header

Posted on by

Engine.io介紹

Engine.io介紹

Socket.io是在engine.io的基礎上去實作的
Gitlab連結: Engine.IO: the realtime engine
engine.io為socket.io提供跨瀏覽器/跨設備的雙向通信的底層庫。engine.io使用了Websocket和XHR方式封裝了一套socket協議。在低版本的瀏覽器中，不支持Websocket，為了兼容使用長輪詢( polling )替代。

關於長輪詢可參考我的另一篇文章:WebSocket與Ajax的不同
過去WebSocket未出來時，許多聊天室使用的都是長輪詢的方式去實作，而engine.io則可依據客戶端環境兼容使用這兩種方式。
Continue reading Engine.io介紹

Posted on by

Redis Sentinel

Sentinel特性

Redis Sentinel為Redis提供高可用性。實際上，這意味著使用Sentinel可以創建Redis部署，該部署可以在沒有人工干預的情況下抵抗某些類型的故障。

Redis Sentinel還提供其他附帶任務，例如監視，通知，並充當客戶端的配置提供程序。

這是宏觀上Sentinel功能的完整列表（即，大圖）：

監控。Sentinel會不斷檢查您的主實例和副本實例是否按預期工作。
通知。Sentinel可以通過API通知系統管理員或其他計算機程序，其中一個受監視的Redis實例出了問題。
自動故障轉移。如果主服務器未按預期工作，則Sentinel可以啟動故障轉移過程，在該過程中將副本升級為主服務器，將其他附加副本重新配置為使用新的主服務器，並通知使用Redis服務器的應用程序要使用的新地址。連接時。
配置提供程序。Sentinel充當客戶端服務發現的授權來源：客戶端連接到Sentinels，以詢問負責給定服務的當前Redis主服務器的地址。如果發生故障轉移，Sentinels將報告新地址。

Redis Sentinel是一個分佈式系統：

Sentinel本身設計為在有多個Sentinel進程協同合作的配置中運行。具有多個Sentinel進程進行協作的優點如下：

當多個哨兵就給定的主機不再可用這一事實達成共識時，將執行故障檢測。這降低了誤報的可能性。
即使不是所有的Sentinel進程都在工作，Sentinel仍能正常工作，從而使系統能夠應對故障。畢竟，擁有故障轉移系統本身就是一個單點故障，這沒有任何樂趣。
Continue reading Redis Sentinel