學習使用wifidog一段時間了，覺得這玩意真的不錯，雖然有些程式碼寫的不夠嚴謹，執行效率不夠高，但是少量人數情況下實現portal是很好的方案。

下面是我摘自一個部落格的內容和apfree寫的文件中的一部分發上來的，希望能對研究wifidog的新人給予幫助！

一. 使用者上線

1. 使用者訪問網路，通過iptables將未認證的使用者dnat到wifidog程序，wifidog通過307報文將使用者重定向到認證伺服器

2. 使用者開啟認證伺服器登入頁面，輸入使用者名稱密碼，傳送認證請求

3. 認證成功的話伺服器會發送302報文，攜帶token資訊重定向到wifidog頁面。認證失敗的話會返回失敗頁面

4. 使用者攜帶token資訊向wifidog發起認證請求，wifidog再向認證伺服器發起請求，認證成功後授權，並將使用者重定向到成功頁面

二. 保活和下線

1. wifidog會定時向認證伺服器傳送保活訊息

2. 當用戶主動請求下線後，wifidog此時並沒有下線

3. 當wifidog再次發起保活請求時，認證伺服器會告訴它使用者已下線，此時wifidog會將使用者下線

認證流程描述（摘自apfree wifidogV2協議文件）

i.Wifidog執行之後建立一系列的防火牆規則，主要規則起到如下作用：1.阻斷所有內網到外網的訪問。2.開通內網到外網的dns訪問。3.開通內網到認證伺服器以及域名白名單的訪問。4.對內網到外網80埠的訪問轉向到wifidog自己的http服務（2060埠）

ii. 手機、pc連線上來後，app或者系統（安卓、ios會自己連線到各自的伺服器上來驗證網路的連通性）會發起對外網的訪問請求，dns請求會被放過，然後對應的80埠的訪問會被指向2060的http服務，其他的請求都會被攔截

iii. Wifidog的http接到web請求後，基本上都會被指向404頁面，404頁面會給客戶端一個重定向返回（302），要求客戶端重定向訪問認證伺服器的login頁面，附加引數gw_id、gw_address、gw_port、url

iv. 手機、pc客戶端載入、顯示認證伺服器的login頁面，使用者根據頁面內容做相關的認證操作（qq登入、微博登入、使用者名稱密碼登入、手機簡訊登入等多種登入方式），原則只有一個認證不成功就仍然讓使用者停留在認證伺服器繼續認證操作，認證成功給客戶端一個302重定向返回，根據login介面提交上來的引數gw_address

v.Wifidog的web服務收到手機、pc客戶端的/wifidog/auth請求後，會主動對認證伺服器的auth介面發起一個驗證請求，附帶引數ip、mac、token、stage=login

vi. 認證伺服器的auth介面收到wifidog的請求，要根據內部邏輯返回是否允許通過的應答Auth: 0拒絕Auth: 1 允許

vii. Wifidog接收到驗證結果後，如果拒絕訪問，就會返回302給客戶端，重定向到認證伺服器的gw_message介面，附帶message=denied引數，客戶端的上網訪問仍然會回到第二步驟；如果允許訪問，則改動防火牆規則，開通改客戶端的上網（至此客戶端已經能夠正常上網），然後返回302重點向給客戶端，重定向到認證伺服器的portal介面，附帶引數gw_id

viii. 認證伺服器的的portal介面根據業務流成顯示廣告業或者做其他的跳轉

ix. 整個認證流程完成