蘋果手機連接Wifi認證機制


 

Wifi狀態保持方法和nas設備

https://patents.google.com/patent/CN106793171A/zh

 

基於ios終端的離線wifi熱點認證方法和認證系統

https://patents.google.com/patent/CN105245540A/zh

一種簡單的基於HTTP重定向的Captive Portal實現

 

當網關收到來自客戶端的HTTP請求,例如:

GET http://www.example.com/

  

網關可以返回如下內容給客戶端:

<meta HTTP-EQUIV='REFRESH' content='0; url=http://<your auth server ip>/login'>

  

 

 

關於Apple的Captive Network Assistant

 

在WIFI的應用場景中,有個很典型的應用,叫做Captive Portal,也叫Captive Web Portal(CWP)。

大致流程是:

用戶的移動設備(例如手機)接入WIFI。
打開任意網頁。
得到一個類似Login的頁面,需要用戶填寫一些信息,然后提交。
認證通過后,允許自由訪問網絡,否則無法上網。
電信、移動等運營商經常會推出一些市區里的WIFI,很多用的就是這種方式。還有像機場等地。有個典型的應用,就是杭州的ihangzhou。

iOS,還有Mac OS,都有個功能,當接入無線網絡后,會自動檢測網絡是否通。如果不通,則會自動彈出一個頁面,讓用戶去登錄。

Apple把這種功能叫做Captive Network Assistant(CNA)。

其原理如下:

發送一個HTTP/1.0的請求到 http://www.apple.com/library/test/success.html 
接收一個回應,如果回應跟它預計的結果一致,那么認為網絡是通的,就不會自動彈出頁面。同時,狀態欄的WIFI圖標出現。流程結束。否則,進入下一步。
如果收到的回應不是它想要的那個,它就認為有CWP存在。
如果有CWP存在,iOS就會自動打開一個頁面,在這個頁面中再請求一次http://www.apple.com/library/test/success.html,這一次,使用的是HTTP/1.1。
然后就可以打開Login頁面了。
在第2步中,如果有CWP存在,收到的回應通常是一個Login頁面,這個和第5步收到的結果應該是一樣的。
如果網絡能,則可以收到下面的回應。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
只是第2步中,iOS是如何判斷的,不得而知。不過只要保證收到上面的響應,則一定能通。

那么,第2步中如果沒有收到響應,或是收到了非HTTP 200的響應又會如何呢?

根據我的測試,如果沒收到響應,依然會彈出一個窗口。不過,這不是一種正常的CWP狀態。

非HTTP 200的情況,我只試了HTTP 302重定向。在這種情況下,iOS不會自動彈出Login頁面。

在上面的5步中,得到了一個Login頁面,然后又會發生什么呢?

用戶拿到Login頁面后,應該填寫一些信息,並且提交。iOS會在用戶提交后,立即發一邊第1步中的請求,再次檢測網絡。如果此時網絡還是不通,iOS會自動斷開當前的SSID。不過這個行為好像有點不穩定,具體就不細說了。

網絡通了后,在iOS上基本有2個現象。一是右上角的“取消”按鈕變成”完成“,或是自動關閉這個窗口,行為似乎不太一致。最關鍵的是頂端狀態欄WIFI圖標的出現。

從現象上看,只要WIFI圖標不出來,iOS就不允許有流外出(部分特殊的除外)。

********** 副作用 **********

iOS的這種行為,其實沒給用戶多少方便,卻會帶來不少麻煩。我記得在iOS 4時,還可以選擇是否啟用auto-login。不過iOS 6已經沒有這個選項了。

理論上講,這個功能最麻煩的就是要保證你所在的網絡可以訪問http://www.apple.com/library/test/success.html。如果僅僅是在公司內部網絡,不允許訪問外網,那么iOS就無法連接了。

【題外話】在iOS 5以前,只有open的SSID才會發test請求。(open的SSID指的是沒有802.1X或PSK認證的)。而從iOS 6開始,連上非open的網絡也會發這個test了。

所以,在這種內網的情況下,需要防火牆開放www.apple.com的訪問,或是WIFI AP可以支持避開CNA的檢測。

我一直沒在網上找到關於CNA的判斷標准,不知道Apple搞這么個東西干嗎。

********** 測試結果 **********

寫完此文,心里一直癢癢的,想知道第2步究竟是怎么判斷的。於是立即動手測試。

我發現,只要響應頁面中,<TITLE>的值是Success,大小寫敏感,就可以欺騙iOS了。

測了iOS 6.0和Mac OS 10.7,結果都一樣。這下我心里釋懷了。不知道新版本會不會有變化。該死的蘋果。
---------------------
作者:permike
來源:CSDN
原文:https://blog.csdn.net/permike/article/details/47417317
版權聲明:本文為博主原創文章,轉載請附上博文鏈接!

 

 

 

[0035] 實施例1、

[0036] 本發明實施例提供了一種WIFI狀態保持方法,參照圖3中所示,包括:

[0037] S20UNAS設備接收I0S終端發送的探測報文,探測報文用於探測蘋果服務器是否 可達。

[0038] S202、當判斷接收到探測報文為I0S終端顯示Portal認證界面之后的探測報文時, NAS設備構造並響應第一響應報文,其中,第一響應報文的主體部分指示蘋果服務器響應成 功。

[0039] 當I0S終端顯示Portal認證界面之后,如果探測報文探測蘋果服務器可達,則會保 持WIFI連接,並點亮WIFI圖標,不會因為用戶離開Portal認證界面導致認證過程中斷。本發 明實施例即利用NAS設備來構造並響應一個響應報文,提前指示蘋果服務器可達,以提前實 現上述目的。

[0040] 本發明實施例提供的WIFI狀態保持方法,由NAS設備針對I0S終端在顯示Portal認 證界面之后的探測報文來構造一個響應報文,使得I0S終端認為探測成功,從而使WIFI圖標 提前被點亮,並且不會因為用戶離開Portal認證界面而中斷WIFI連接,解決了 I0S終端由於 自身CNA機制,在認證通過前離開Portal頁面時會導致該I0S終端自動斷開WIFI的問題。 [0041] 實施例2、

[0042] 本發明實施例提供了另一種WIFI狀態保持方法,參照圖4中所示,包括:

[0043] S301、I0S 終端連接 WIFI 后,主動向 NAS 設備發起 DHCP (dynamic host conf iguration protocol,動態主機配置協議)Discover (發現)報文,請求獲取ip (internet protocol,網絡協議)地址。

[0044] S3〇2、NAS設備收到IOS終端發起的DHCP Discover報文后,為該IOS終端分配IP地 址,同時記錄I0S終端的MAC地址並初始化接收到來自該l〇s終端的HTTP 1 .OGet hotspot-detect.html探測報文的狀態標識。

[0045] 具體的,可以預先創建一張I0S終端CNA探測狀態表,每條記錄包括MAC地址字段和 狀態標識(Status)字段。在NAS設備收到I0S終端發起的DHCP Discover報文后,在上述I0S 終端CNA探測狀態表中寫入一條數據:MAC地址字段中記錄I0S終端MAC,狀態標識字段設置 為0,其中,Status字段指不NAS設備首次接收到該I0S終端所發送的HTTP 1 .OGet hotspot-detect .html探測報文的狀態。

[0046] 3303、103終端獲取到財3設備分配的1?地址后,發起111^?1.(^以11的邛〇七- detect. html探測報文。

[0047] 通常I 0 S終端的探測地址為:c a p t i ve.apple.com、www.airport.us、 www.ibook.infonwww.thinkdifferent.us>www.appleiphonecel1.com>www.itooIs. info 六個地址中的任意一個。

[0048] S304、NAS設備判斷該I0S終端發起的HTTP 1 .OGet hotspot-detect.html探測報 文是否為首次HTTP 1 • OGet hotspot-detect • html探測報文,如果為首次,則NAS設備則構 造並響應HTTP 2000K報文,報文內容的主體部分為失敗(Failed),指示蘋果服務器響應失 敗,此時I0S終端的WIFI圖標未點亮。

[0049] 本步驟中,NAS設備攔截該HTTP 1 .OGet hotspot-detect.html探測報文,根據維 護的I0S終端CNA探測狀態表中的狀態標識(Status)字段判斷I0S終端發送的探測報文是否 為I0S終端顯示Portal認證界面之后的首次HTTP1.0探測報文,若Status字段為0,返回HTTP 2〇0〇K,報文內容的Body部分為Failed,同時將終端CNA探測狀態表中該MAC地址對應的 Status更新為1,此時I0S終端的Wi-Fi圖標未點亮。

[0050] 需要說明的是,本發明實施例中,狀態標識字段設置為0標識NAS設備首次接收到 該I0S終端所發送的HTTP 1.OGet hotspot-detect.html探測報文的狀態,狀態標識字段設 置為1標識NAS設備非首次接收到該I0S終端所發送的HTTP 1 .OGet hotspot-detect.html 探測報文的狀態;當然也可以采用其它標識方式,例如狀態標識字段設置為1標識NAS設備 首次接收到該I0S終端所發送的HTTP 1_OGet hotspot-detect.html探測報文的狀態,狀態 標識字段設置為〇標識NAS設備非首次接收到該I0S終端所發送的HTTP l.OGet hotspot-detect.html探測報文的狀態;當然也可以采用其它標識方式,只要事前進行定義NAS設備 識別到狀態變化即可,在此不再贅述。

[0051] 此時的HTTP l.OGet hotspot-detect.html探測報文為第二響應報文。

[0052] S305、I0S終端接收到NAS設備響應的HTTP 2000K報文之后,發起HTTP l.lGet hotspot-detect. html 請求報文。

[0053] S3〇6、NAS設備判斷該I0S終端發起的HTTP l.lGet hotspot-detect.html請求地 址是否在NAS設備的白名單列表中或者當前10S終端是否己認證通過,如果請求地址不在 NAS設備的白名單列表中並且當前I0S終端未認證通過,則NAS設備響應HTTP 302報文,將 Portal認證頁面地址通過HTTP 302報文返回給I0S終端,此時I0S終端的WIFI圖標未點亮。 [0054] S307、I0S終端收到NAS設備根據HTTP l.lGet hotspot-detect.html請求所返回 的HTTP 302請求報文后,請求HTTP 302報文中攜帶的Portal認證頁面地址,此時I0S終端顯 示Portal認證頁面。

[0055] S3〇8、IOS終端再次向NAS設備發起HTTP l.OGet hotspot-detect.html探測報文。

[0056] S309、NAS設備通過判斷該HTTP 1 .OGet hotspot_detect.html探測報文是否為首 次HTTP 1 • OGet hotspot-detect • html探測報文,如果不為首次(即為I0S終端顯示Portal 認證頁面之后的HTTP l.OGet hotspot-detect.html探測報文),則構造並響應HTTP 2000K 報文,報文內容的主體(Body)部分為成功(Success),指示蘋果服務器響應成功,此時WIFI 圖標點殼。

[0057] 具體的,NAS設備可以通過I0S終端CNA探測狀態表中的Status字段來判斷是否為 首次HTTP 1 .OGet hotspot-detect.html探測報文。WIFI圖標點亮原因參照步驟S202,在此 不再贅述。

[0058] 此時的HTTP l.OGet hotspot-detect.html探測報文為第一響應報文。

[0059] S310、I0S 終端持續發起 HTTP l.OGet hotspot-detect .html 探測報文。

[0060] S311、NAS設備通過判斷該HTTP l.OGet hotspot-detect.html探測報文是否為首 次HTTP l.OGet hotspot-detect.html探測報文,如果不為首次,則響應HTTP 2000K報文, 報文內容的主體(Body)部分為成功(Success),此時WIFI圖標保持亮起狀態。

[0061] 具體的,NAS設備可以通過終端CNA探測狀態表中的Status字段來判斷是否為首次 HTTP 1 .OGet hotspot-detect.html探測報文。WIFI圖標點亮原因參照步驟S202,在此不再 贅述。

[0062] 本發明實施例提供的WIFI狀態保持方法,通過NAS設備在檢測到I0S終端顯示 Portal認證頁面之后發送的HTTP l.OGet hotspot-detect .html探測報文時,響應HTTP 2000K報文,並且在報文中包含指示成功的內容,使得I0S終端認為探測成功,從而使WIFI圖 標提前被點亮,並且不會中斷WIFI連接,解決了I0S終端由於自身CNA機制,在認證通過前離 開Portal頁面時會導致該I0S終端自動斷開WIFI的問題。

[0063] 實施例3、

[0064] 本發明實施例提供了一種NAS設備,應用於上述WIFI狀態保持方法,參照圖5中所 示,包括:

[0065] 接收單元1401,用於接收I0S終端發送的探測報文,探測報文用於探測蘋果服務器 是否可達;

[0066] 發送單元1402,用於判斷當接收到的探測報文為I0S終端顯示Portal認證界面之 后的探測報文時,NAS設備構造並響應第一響應報文,其中,第一響應報文的主體部分指示 蘋果服務器響應成功。

[0067] 在一種可能的設計中,探測報文為HTTP 1 .OGet hotspot-detect.html探測報文。

[0068] 在一種可能的設計中,響應報文為HTTP 2000K報文,HTTP 2000K報文的主體部分 為成功Success。

[0069] 在一種可能的設計中,發送單元1402還用於:當接收到的探測報文不為I〇S終端顯 示Portal認證界面之后的探測報文時,構造並響應第二響應報文,其中,第二響應報文的主 體部分指示蘋果服務器響應失敗。

[0070] 在一種可能的設計中,發送單元14〇2還用於:在接收到I0S終端發起的DHCP Discover報文后,在預先創建的I0S終端CNA探測狀態表中記錄I〇S終端的MAC地址及對應的 接收探測報文的狀態標識;並在首次接收到I〇S終端發起HTTP1.0探測報文后更新狀態標 識,根據狀態標識判斷接收到的探測報文是否為I〇S終端顯示Portal認證界面之后的探測 報文。

[0071] 由於本發明實施例中的NAS設備可以應用於上述WIFI狀態保持方法,因此,其所能 獲得的技術效果也可參考上述方法實施例,本發明實施例在此不再贅述。

[0072] 應理解,在本發明的各種實施例中,上述各過程的序號的大小並不意味着執行順 序的先后,各過程的執行順序應以其功能和內在邏輯確定,而不應對本發明實施例的實施 過程構成任何限定。

[0073] 本領域普通技術人員可以意識到,結合本文中所公開的實施例描述的各示例的單 元及算法步驟,能夠以電子硬件、或者計算機軟件和電子硬件的結合來實現。這些功能宄竟 以硬件還是軟件方式來執行,取決於技術方案的特定應用和設計約束條件。專業技術人員 可以對每個特定的應用來使用不同方法來實現所描述的功能,但是這種實現不應認為超出 本發明的范圍。

[0074] 所屬領域的技術人員可以清楚地了解到,為描述的方便和簡潔,上述描述的系統、 裝置和單元的具體工作過程,可以參考前述方法實施例中的對應過程,在此不再贅述。

[0075] 在本申請所提供的幾個實施例中,應該理解到,所揭露的系統、設備和方法,可以 通過其它的方式實現。例如,以上所描述的設備實施例僅僅是示意性的,例如,所述單元的 划分,僅僅為一種邏輯功能划分,實際實現時可以有另外的划分方式,例如多個單元或組件 可以結合或者可以集成到另一個系統,或一些特征可以忽略,或不執行。另一點,所顯示或 討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口,設備或單元的間接耦 合或通信連接,可以是電性,機械或其它的形式。

[0076] 所述作為分離部件說明的單元可以是或者也可以不是物理上分開的,作為單元顯 示的部件可以是或者也可以不是物理單元,即可以位於一個地方,或者也可以分布到多個 網絡單元上。可以根據實際的需要選擇其中的部分或者全部單元來實現本實施例方案的目 的。

[0077]另外,在本發明各個實施例中的各功能單元可以集成在一個處理單元中,也可以 是各個單元單獨物理存在,也可以兩個或兩個以上單元集成在一個單元中。

[0078] 所述功能如果以軟件功能單元的形式實現並作為獨立的產品銷售或使用時,可以 存儲在一個計算機可讀取存儲介質中。基於這樣的理解,本發明的技術方案本質上或者說 對現有技術做出貢獻的部分或者該技術方案的部分可以以軟件產品的形式體現出來,該計 算機軟件產品存儲在一個存儲介質中,包括若千指令用以使得一台計算機設備(可以是個 人計算機,服務器,或者網絡設備等)執行本發明各個實施例所述方法的全部或部分步驟。 而_述的存儲介質包括:U盤、移動硬盤、只讀存儲器(英文全稱:read-only memory,英文簡 稱:ROM)、隨機存取存儲器(英文全稱:random access memory,英文簡稱:RAM)、磁碟或者光 盤等各種可以存儲程序代碼的介質。

[0079]以上所述,僅為本發明的具體實施方式,但本發明的保護范圍並不局限於此,任何 熟悉本技術領域的技術人員在本發明揭露的技術范圍內,可輕易想到變化或替換,都應涵 蓋在本發明的保護范圍之內。因此,本發明的保護范圍應以所述權利要求的保護范圍為准。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM