咱們去大多數機場或者一些公共場合的時候,會看到不少公共的WIFI熱點須要進行手機號的短信認證登陸,那麼咱們如何去構造這樣一個系統呢?微信
這裏介紹一種技術——wifidog,其提供了一套這樣的解決方案,適用於openwrt和ddwrt,其包括了兩個部分路由端須要安裝的插件,以及一個提供的基於XMPP的web解決方案,我看了下以爲若是使用它提供的web解決方案的話,很是不方便,由於這樣的技術通常只要弄清楚其通訊的機制和協議就能夠了,因此在文檔中找到了其通訊的協議,以後我會加以說明其相關的協議。網絡
具體的原理是怎樣?又是如何實現的。tcp
首先咱們須要一個能夠進行命令行管理操做的路由器,好比刷過相似於openwrt或者ddwrt這種系統的路由器,這樣的一個系統相似於一個小的Linux系統,若是咱們能夠進行命令行的控制,那麼咱們就能夠安裝一系列的軟件了,這裏咱們經過給路由器安裝wifidog,實現構建這樣一個WIFI認證的系統。那麼wifidog是如何實現整個過程的呢?ide
簡單來說就是路由層會將全部的用戶mac地址進行一個名單的控制,因此在未登陸認證以前,而後wifidog能夠配置一個登陸受權的服務器地址,用戶不在白名單列表裏,就會被重定向到這個網址。post
通常來說,其實全部的網絡訪問應該都是不能夠的,可是藉助於iptables的管理,路由器能夠設定一些ip以及相關協議(tcp, udp)的白名單,因此對於認證過程當中可能設計到網頁,包括中間須要網絡請求提交的地址(例如新浪或者QQ等第三方的登陸受權)都須要加入到訪問網絡地址的白名單裏面。這樣能夠保證用戶基本的網絡訪問權限的限制嗎,可是同時又不影響網絡的受權。spa
當用戶被重定向到了認證的網頁以後,剩下的操做就在認證服務器端進行了,但須要保證的是,由於如今用戶的基本網絡訪問權限是被限制住的,因此中間全部涉及到的網絡請求地址都須要按照上面說的給加入到白名單裏面,不然由於一些請求發送不出去,因此不能完成認證。插件
對於認證的過程,根據上述的描述,由於認證操做都在認證服務器端,因此能夠保證認證過程是很是靈活。就好比說 咱們常見的是短信驗證碼的認證,除此以外,咱們能夠用新浪微博登陸,微信添加賬號,動態密碼,豆瓣人人登陸等等,由於通常第三方登陸都是基於XOAuth或者OAuth2.0認證,因此通常都是無非有一個登陸的地址,而後一個回調的地址,可是須要注意的是,第三方登陸頁面會有一些JS或者CSS資源之類的,這些資源可能不在同域下面,而一些圖片顯示,最重要登陸驗證提交都是在JS裏面,因此也須要抓包分析一下地址,進行路由器的配置白名單。
如今不少人可能有疑問是,認證操做是在服務器端進行的,那麼認證經過後,認證服務器是如何告知路由器用戶已經經過受權呢?
其實由於用戶此時在內網,因此wifidog的解決方案是,在內網的一個ip地址開了一個端口(通常是2620),接受HTTP的請求,因此認證服務器認證成功以後須要給用戶生成一個惟一的token標識,而後重定向到這個http請求地址並帶上參數便可。
而後路由器這邊接受到了請求以後,就會認爲這個用戶(實際判斷是mac地址)能夠進行網絡訪問,可是呢,實際上也不會這麼直接開放用戶網絡權限,由於通常來講咱們用CMCC的話是否是會看到用戶已經上網的時長呢,因此這裏wifidog也提供了一個用戶的控制,具體是怎樣的呢?
就是在用戶認證成功以後,路由器不是獲得了用戶的token嗎,而後token和mac以及ip能夠構成惟一,因此路由器會週期性地把這三個值以及鏈接信息(其餘參數)一塊兒發給認證服務器,認證服務器經過返回值來斷定該用戶當前的狀態,好比是能夠繼續網絡訪問呢,仍是拒絕,仍是驗證失敗,仍是出錯等等,來控制用戶的訪問權限。
例如實現三個小時剔除用戶的話,就能夠從用戶認證經過開始計時,若是超過三小時,當路由器三小時後週期性發來驗證信息的時候,能夠返回拒絕,而後用戶就會被踢下線。
整個邏輯也就是: 用戶認證服務器經過後,會重定向到路由器的http認證地址,路由器獲取用戶的token,開始對其進行週期性的驗證,由認證服務器對其進行鑑權。
有的時候由於須要判斷路由器這邊的認證受權控制是否正常工做,因此路由器會一直對認證服務器進行心跳包的發送,可讓認證服務器監控到路由器是否正常工做。
以上就是藉助wifidog的原理,對WIFI認證登陸控制的整個限制的過程分析,這裏主要是基於wifidog v1的協議和原理。 歡迎多多交流。
本文章由 http://www.wifidog.pro/2015/02/11/wifidog-cmcc.html 整理編輯,轉載請註明出處