基于APP應(yīng)用的Portal認證方法及其裝置制造方法
【專利摘要】本發(fā)明公開了一種基于APP應(yīng)用的Portal認證方法及其裝置，應(yīng)用于接入設(shè)備上，該方法包括：接收用戶終端向APP應(yīng)用服務(wù)器發(fā)起的TCP三次握手連接請求，判斷連接請求是否已通過Portal認證或者在白名單內(nèi)，若是，則轉(zhuǎn)發(fā)用戶終端的TCP連接請求報文，使用戶終端與APP應(yīng)用服務(wù)器建立TCP連接；否則仿冒APP應(yīng)用服務(wù)器與用戶終端建立TCP連接；接收用戶終端發(fā)送的Http的Get請求報文，解析該報文中的URL，將APP應(yīng)用服務(wù)器的IP地址加入到白名單內(nèi)，向用戶終端返回RST報文，通知用戶終端向APP應(yīng)用服務(wù)器重新發(fā)起TCP三次握手連接請求。本發(fā)明利用在APP應(yīng)用中推廣公眾號的形式，提高企業(yè)競爭力，推廣企業(yè)形象。
【專利說明】基于APP應(yīng)用的Porta I認證方法及其裝置

【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及通信【技術(shù)領(lǐng)域】，尤其涉及一種基于APP應(yīng)用的Portal認證方法及其裝 置。

【背景技術(shù)】
[0002] Portal認證技術(shù)是一種簡單易用的身份認證技術(shù)，其主要目的是為了驗證接入網(wǎng) 絡(luò)客戶端的身份。未認證用戶上網(wǎng)時，設(shè)備強制用戶登錄到特定門戶網(wǎng)站站點，用戶可以免 費訪問其中的服務(wù)。當用戶需要使用互聯(lián)網(wǎng)中的其他信息時，必須在門戶網(wǎng)站進行認證，只 有認證通過后才可以使用互聯(lián)網(wǎng)資源。
[0003] 具體地，用戶可以主動訪問已知的Portal認證網(wǎng)站，輸入用戶名和密碼進行認 證，這種開始Portal認證的方式稱作為主動認證；反之，如果用戶試圖通過HTTP訪問其他 外網(wǎng)，將被強制訪問Portal認證網(wǎng)站，從而開始Portal認證過程，這種方式稱作強制認證。 Portal業(yè)務(wù)可以為運營商提供方便的管理功能，門戶網(wǎng)站可以開展廣告、社區(qū)服務(wù)、個性化 的業(yè)務(wù)等，使寬帶運營商、設(shè)備提供商和內(nèi)容服務(wù)商形成一個產(chǎn)業(yè)生態(tài)系統(tǒng)。
[0004] 隨著寬帶無線接入和智能移動終端技術(shù)的飛速發(fā)展，人們迫切希望能夠隨時隨地 乃至在移動過程中都能方便地從互聯(lián)網(wǎng)獲取信息和服務(wù)，移動互聯(lián)網(wǎng)應(yīng)運而生并迅猛發(fā) 展，隨著智能移動終端類型的不斷發(fā)展，各種APP應(yīng)用發(fā)展越來越快，典型的例如微信已經(jīng) 發(fā)展到6億用戶，圍繞微信而發(fā)展的各種APP應(yīng)用也開始層出不窮。Portal認證本身為網(wǎng) 頁認證，在移動互聯(lián)網(wǎng)時代，很多用戶訪問各種應(yīng)用已經(jīng)不經(jīng)過瀏覽器，而是直接通過各種 APP，因此APP中內(nèi)嵌Portal認證是非常重要的一個功能。
[0005] 現(xiàn)有技術(shù)中，通過AC(Access Controller,接入控制器）將所有微信服務(wù)器對應(yīng) 的IP地址在接入設(shè)備上都配置為白名單；然后用戶終端打開微信客戶端后發(fā)起DNS請求， DNS服務(wù)器返回該域名對應(yīng)的IP地址；進而用戶終端和微信服務(wù)器地址的80端口建立連 接，此時由于微信服務(wù)器地址為白名單規(guī)則，因此直接建立連接；用戶終端直接與微信服務(wù) 器通過通信交互，用戶登錄成功；用戶終端在微信中打開Portal served門戶網(wǎng)站服務(wù) 器）的公眾號，內(nèi)嵌的Portal server推出認證頁面，用戶輸入用戶名和密碼進行認證；用 戶在微信中認證成功并可以訪問微信中的其他公眾號資源。然而該認證方式中，由于用戶 必須先能夠登陸微信成功，因此微信服務(wù)器必須先放行，必須事先知道微信服務(wù)器對應(yīng)的 IP地址，并將這些地址添加到白名單中。但是，對于微信這種用戶量大的應(yīng)用，隨著用戶規(guī) 模不斷增加，部署的服務(wù)器會越來越多，每次需要網(wǎng)管人員手動增加，維護工作會越來越繁 瑣、越來越復(fù)雜。


【發(fā)明內(nèi)容】

[0006] 有鑒于此，本發(fā)明提出一種簡化portal認證方式的基于APP應(yīng)用的Portal認證 方法及其裝置。
[0007] 為了到達上述目的，本發(fā)明所采用的技術(shù)方案為：
[0008] -種基于APP應(yīng)用的Portal認證方法，應(yīng)用于接入設(shè)備上，其中，所述方法包括：
[0009] 接收用戶終端向APP應(yīng)用服務(wù)器發(fā)起的TCP三次握手連接請求，判斷該連接請求 是否已通過Portal認證或者在白名單內(nèi)，若是，則轉(zhuǎn)發(fā)所述用戶終端的TCP三次握手連接 請求報文，使所述用戶終端與所述APP應(yīng)用服務(wù)器建立TCP三次握手連接，以便所述用戶終 端在該APP應(yīng)用中通過內(nèi)嵌的Portal頁面進行認證；否則，仿冒所述APP應(yīng)用服務(wù)器與所 述用戶終端建立TCP三次握手連接；
[0010] 接收所述用戶終端發(fā)送的Http的Get請求報文，解析該報文中的URL，將所述APP 應(yīng)用服務(wù)器的IP地址并將其加入到白名單內(nèi)，向用戶終端返回RST報文，通知用戶終端向 所述APP應(yīng)用服務(wù)器重新發(fā)起TCP三次握手連接請求。
[0011] 進一步地，在用戶終端向APP應(yīng)用服務(wù)器發(fā)起TCP三次握手連接請求之前還包 括：
[0012] 所述用戶終端向DNS服務(wù)器發(fā)起所述APP應(yīng)用的DNS請求，獲取該APP應(yīng)用服務(wù) 器的IP地址。
[0013] 進一步地，用戶終端向APP應(yīng)用服務(wù)器發(fā)起的TCP三次握手連接請求認證通過后， 所述用戶終端在APP應(yīng)用中通過內(nèi)嵌的Portal頁面進行認證的具體步驟包括：
[0014] 所述用戶終端在APP應(yīng)用中打開Portal服務(wù)器的公眾號，內(nèi)嵌的Portal服務(wù)器 推出認證頁面，所述APP用戶終端通過認證后可正常訪問互聯(lián)網(wǎng)資源。
[0015] 進一步地，所述APP應(yīng)用中的Portal服務(wù)器公眾號通過所述用戶終端在第一次網(wǎng) 頁認證時，通過掃描網(wǎng)頁中內(nèi)嵌廣告推廣公眾號以加入到公眾號中。
[0016] 進一步地，所述接入設(shè)備在仿冒所述APP應(yīng)用服務(wù)器的同時，存儲用戶終端的識 別信息以及APP應(yīng)用服務(wù)器的IP地址信息。
[0017] 進一步地，將所述APP應(yīng)用服務(wù)器的IP地址加入到白名單內(nèi)，具體包括：
[0018] 當所述用戶終端發(fā)起Http的Get請求時，所述接入設(shè)備通過解析URL獲取所述 APP應(yīng)用的域名信息，并根據(jù)該域名判斷是否需要將APP應(yīng)用加入白名單內(nèi)，如果是，則根 據(jù)保存的用戶終端識別信息將所述域名與APP應(yīng)用服務(wù)器的IP地址關(guān)聯(lián)，進而將該APP應(yīng) 用服務(wù)器的IP地址加入白名單，而后發(fā)送RST報文給所述用戶終端。
[0019] 本發(fā)明同時提供一種基于APP應(yīng)用的Portal認證裝置，其中，所述認證裝置包 括：
[0020] 判斷單元，用于當接收用戶終端向APP應(yīng)用服務(wù)器發(fā)起的TCP三次握手連接請求 后，判斷該連接請求是否已通過Portal認證或者在白名單內(nèi)，若是，則通知轉(zhuǎn)發(fā)單元進行 處理，否則通知處理單元進行處理；
[0021] 轉(zhuǎn)發(fā)單元，用于接收到判斷單元的通知后，轉(zhuǎn)發(fā)用戶終端的TCP三次握手連接請 求報文，使用戶終端與APP應(yīng)用服務(wù)器建立TCP連接，以便用戶終端在該APP應(yīng)用中通過內(nèi) 嵌的Portal頁面進行認證；
[0022] 處理單元，用于接收到判斷單元的通知后，仿冒APP應(yīng)用服務(wù)器與用戶終端建立 TCP連接；
[0023] 解析單元，用于接收用戶終端發(fā)送的Http的Get請求報文，解析該報文中的URL， 將APP應(yīng)用服務(wù)器的IP地址加入到白名單內(nèi)，并向用戶終端返回RST報文，通知用戶終端 重新進行TCP三次握手連接。
[0024] 進一步地，所述處理單元在仿冒APP應(yīng)用服務(wù)器的同時，進一步存儲用戶終端的 識別信息以及APP應(yīng)用服務(wù)器的IP地址信息。
[0025] 進一步地，所述解析單元解析URL獲取所述APP應(yīng)用的域名信息后，通知判斷單元 判斷是否需要將APP應(yīng)用加入白名單內(nèi)，如果是，則根據(jù)處理單元保存的用戶終端識別信 息將所述域名與APP應(yīng)用服務(wù)器的IP地址關(guān)聯(lián)，并將該APP應(yīng)用服務(wù)器的IP地址加入白 名單，而后發(fā)送RST報文給所述用戶終端。
[0026] 與現(xiàn)有的技術(shù)相比，本發(fā)明接入設(shè)備通過在用戶終端發(fā)起APP應(yīng)用的TCP三次握 手連接請求時仿冒APP應(yīng)用服務(wù)器，并在與用戶終端TCP三次握手連接建立成功后，進一步 截獲用戶終端發(fā)起的Http Get報文的URL或者主機名稱自動將所述APP應(yīng)用服務(wù)器的IP 地址添加到白名單內(nèi)，因而大幅減化運維人員的工作量，并利用在APP應(yīng)用中推廣公眾號 的形式，提高企業(yè)競爭力，推廣企業(yè)形象。

【專利附圖】

【附圖說明】
[0027] 圖1為本發(fā)明基于APP應(yīng)用的Portal認證方法的流程示意圖；
[0028] 圖2為某應(yīng)用場景下，本發(fā)明基于APP應(yīng)用的Portal認證方法的詳細實現(xiàn)流程 圖；
[0029] 圖3為本發(fā)明基于APP應(yīng)用的Portal認證裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖；以及
[0030] 圖4為本發(fā)明基于APP應(yīng)用的Portal認證裝置的實施例框圖。

【具體實施方式】
[0031] 以下將結(jié)合附圖所示的【具體實施方式】對本發(fā)明進行詳細描述。但這些實施方式并 不限制本發(fā)明，本領(lǐng)域的普通技術(shù)人員根據(jù)這些實施方式所做出的結(jié)構(gòu)、方法、或功能上的 變換均包含在本發(fā)明的保護范圍內(nèi)。
[0032] 本發(fā)明中，在用戶終端安裝熱門APP應(yīng)用，通過在該APP應(yīng)用中內(nèi)嵌Portal認證 的站點，當用戶通過內(nèi)嵌的Portal認證后，便可直接通過APP應(yīng)用訪問各種其他應(yīng)用，從而 不需要經(jīng)過瀏覽器，簡化了用戶訪問其他應(yīng)用的訪問步驟，提高了用戶上網(wǎng)體驗的樂趣，同 時，商家可以通過APP應(yīng)用推廣公眾號的形式，推廣企業(yè)形象，提高企業(yè)競爭力。
[0033] 請參圖1所示，為本發(fā)明基于APP應(yīng)用的Portal認證方法的流程示意圖，該方法 應(yīng)用在接入設(shè)備上，具體地包括：
[0034] S1、接入設(shè)備接收用戶終端向APP應(yīng)用服務(wù)器發(fā)起的TCP三次握手連接請求，判斷 該連接請求是否已通過Portal認證或者在白名單內(nèi)，若是，進入步驟S2,否則轉(zhuǎn)步驟S3 ;
[0035] S2、接入設(shè)備轉(zhuǎn)發(fā)用戶終端的TCP三次握手連接請求報文，使用戶終端與APP應(yīng)用 服務(wù)器建立TCP連接，以便用戶終端在該APP應(yīng)用中通過內(nèi)嵌的Portal頁面進行認證；
[0036] S3、接入設(shè)備仿冒APP應(yīng)用服務(wù)器與用戶終端建立TCP連接；
[0037] S4、接入設(shè)備接收用戶終端發(fā)送的Http的Get請求報文，解析該報文中的 URL (Uniform Resource Locator :統(tǒng)一資源定位器），將APP應(yīng)用服務(wù)器的IP地址加入到 白名單內(nèi)，向用戶終端返回RST(Reset the connection,重置連接）報文，并轉(zhuǎn)步驟S1。
[0038] 進一步地，在步驟S1之前，還包括用戶終端向DNS服務(wù)器發(fā)起APP應(yīng)用的DNS請 求，獲取該APP應(yīng)用服務(wù)器的IP地址。
[0039] 在步驟S2中，APP應(yīng)用中通過內(nèi)嵌的Portal頁面進行認證的具體步驟包括：
[0040] 用戶終端在APP應(yīng)用中打開Portal服務(wù)器的公眾號，內(nèi)嵌的Portal服務(wù)器推出 認證頁面，APP用戶終端通過輸入用戶名和密碼進行認證通過后可正常訪問互聯(lián)網(wǎng)資源；
[0041] 其中，若用戶終端未添加 Portal服務(wù)器的公眾號，所述用戶終端用戶在第一次網(wǎng) 頁認證時，通過掃描網(wǎng)頁中內(nèi)嵌廣告推廣公眾號以加入到公眾號中。
[0042] 在步驟S3中，接入設(shè)備在仿冒APP應(yīng)用服務(wù)器的同時，進一步存儲用戶終端的識 別信息以及APP應(yīng)用服務(wù)器的IP地址信息；
[0043] 在步驟S4中，當所述用戶終端發(fā)起Http的Get請求時，接入設(shè)備通過解析URL獲 取APP應(yīng)用的域名信息，并根據(jù)該域名判斷是否需要將APP應(yīng)用加入白名單內(nèi)，如果是，則 根據(jù)S3步驟中保存的用戶終端識別信息將域名與APP應(yīng)用服務(wù)器的IP地址關(guān)聯(lián)，進而將 該APP應(yīng)用服務(wù)器的IP地址加入白名單，而后發(fā)送RST報文給所述用戶終端。
[0044] 與現(xiàn)有的技術(shù)相比，本發(fā)明接入設(shè)備通過在用戶終端發(fā)起APP應(yīng)用的TCP三次握 手連接請求時仿冒APP應(yīng)用服務(wù)器，并在與用戶終端TCP三次握手連接建立成功后，進一步 根據(jù)截獲用戶終端發(fā)起的Http Get報文的URL或者主機名稱自動將所述APP應(yīng)用服務(wù)器 的IP地址添加到白名單內(nèi)，因而大幅減化運維人員的工作量。
[0045] 如圖2所示，圖2為某應(yīng)用場景下，本發(fā)明基于APP應(yīng)用的Portal認證方法 的詳細實現(xiàn)流程圖，在該認證方法所應(yīng)用的場景中，包括APP客戶端、接入設(shè)備、Portal Server (提供 web 門戶認證頁面的專用服務(wù)器）、Radius (Remote Authentication Dial-In User Service,遠程認證撥號用戶服務(wù)）Server、APP Server (第三方應(yīng)用服務(wù)器）、DNS Server(域名解析服務(wù)器）等。在該應(yīng)用場景下，該方法包括以下步驟：
[0046] 步驟201、APP用戶終端發(fā)送APP Server域名的DNS請求；
[0047] 其中，在實際應(yīng)用中，用戶終端可以為安裝有APP客戶端的電腦、筆記本、手機或 其他移動終端。當需要進行APP應(yīng)用時，用戶終端首先需要發(fā)起該APP應(yīng)用的DNS請求，以 便獲取APP應(yīng)用服務(wù)器的IP地址。
[0048] 步驟202、DNS Server返回提供APP服務(wù)的Server對應(yīng)的IP地址；
[0049] 對于APP熱門應(yīng)用，APP服務(wù)提供商有可能會根據(jù)業(yè)務(wù)需要，同時布署多臺APP Server，在本步驟中，APP用戶終端通過DNS Server，獲取到為其提供APP應(yīng)用服務(wù)的對應(yīng) 服務(wù)器的IP地址。
[0050] 步驟203、用戶終端向APP Server發(fā)起TCP三次握手請求，接入設(shè)備判斷該請 求是否通過Portal認證或者在白名單內(nèi)，若否，接入設(shè)備仿冒APP Server地址和APP Client (APP客戶端）建立三次握手連接，若是，則直接轉(zhuǎn)發(fā)該TCP三次握手連接請求報文 后，轉(zhuǎn)入步驟206處理；
[0051] 用戶終端在獲取到DNS Server返回的為其提供服務(wù)的APP Server的IP地址后， 將發(fā)起向APP Server的TCP三次握手連接請求，接入設(shè)備接收到該APP應(yīng)用的TCP三次握 手連接請求后，判斷是否通過Portal認證或者在預(yù)先配置的白名單內(nèi)，如果否，則接入設(shè) 備將該TCP三次握手連接請求上送至CPU，仿冒APP Server的IP地址和APP Client (APP 客戶端）建立三次握手連接；如果是，則直接轉(zhuǎn)發(fā)該TCP三次握手連接請求報文后，轉(zhuǎn)步驟 206處理。
[0052] 另外，為了能夠?qū)PP Server的IP地址在后續(xù)的步驟中能夠加入到預(yù)先配置的 白名單內(nèi)，在本步驟中，還需要進一步保存該用戶終端的識別信息以及APP Server的IP地 址信息。另外，本發(fā)明接入設(shè)備根據(jù)應(yīng)用場景的不同，有可能是AP(無線接入點）設(shè)備，也 有可能是傳統(tǒng)的接入交換機等，在此不作特別限定。
[0053] 步驟204、A PP用戶終端發(fā)送HTTP的GET報文，接入設(shè)備解析GET報文URL部分 獲取該APP應(yīng)用的域名，并根據(jù)該域名判斷是否將APP Server的IP地址添加到白名單內(nèi)；
[0054] 在接入設(shè)備仿冒APP應(yīng)用服務(wù)器與用戶終端TCP握手成功后，用戶終端發(fā)起Http 的Get請求，接入設(shè)備接收到該請求后，通過解析該Get請求報文的URL部分，從而獲取Get 報文里面攜帶APP應(yīng)用對應(yīng)的域名，并上送CPU判斷是否需要將該域名對應(yīng)的APP應(yīng)用服 務(wù)器的IP地址加入到預(yù)先設(shè)置的白名單內(nèi)，如果是，則進一步根據(jù)前述步驟203保存的用 戶終端信息查找到該APP應(yīng)用服務(wù)器的IP地址，然后將該IP地址加入白名單，并發(fā)送RST 報文給用戶終端。
[0055] 步驟205、APP用戶終端發(fā)起和APP Server重新建立連接；
[0056] 用戶終端接收到接入設(shè)備發(fā)送的RST報文后，將重新發(fā)起和APP Server之間的 TCP三次握手連接。
[0057] 步驟206、APP用戶登錄成功；
[0058] 由于此時所述APP Server對應(yīng)的IP地址已經(jīng)在所述白名單內(nèi)，因此，接入設(shè)備接 收到用戶終端發(fā)起的TCP三次握手連接請求后，直接放行將該報文轉(zhuǎn)發(fā)出去，因此，APP用 戶登錄成功，APP應(yīng)用終端與APP Server建立起通信連接。
[0059] 步驟 2〇7、APP Client 訪問 Portal Server 公眾號；
[0060] 用戶APP應(yīng)用登錄成功后，當需要在APP應(yīng)用中打開Portal服務(wù)器的公眾號， 則內(nèi)嵌的Portal Server推出認證頁面，如果用戶終端沒有添加 Portal Server的公眾 號，則在第一次網(wǎng)頁認證時，可以通過掃描網(wǎng)頁中內(nèi)嵌廣告推廣公眾號的方式加入Portal Server的公眾號。
[0061] 步驟208、Portal Server發(fā)送登錄頁面；
[0062] 步驟209、用戶輸入用戶名和密碼；
[0063] 步驟210、用戶認證信息發(fā)送到接入設(shè)備；
[0064] 步驟211、接入設(shè)備發(fā)送認證信息給Radius Server ;
[0065] 步驟212、Radius Server返回認證結(jié)果給接入設(shè)備；
[0066] 步驟213、接入設(shè)備將認證結(jié)果通過HTTP報文發(fā)送給Portal Server。
[0067] 步驟208-213為Portal認證的過程，當APP客戶端訪問Portal Server公眾號時， Portal Server發(fā)送登錄頁面，用戶終端通過輸入用戶名和密碼，當認證通過后用戶終端即 可正常訪問在該APP應(yīng)用上注冊的其他公眾號資源了，由于上述步驟與現(xiàn)有技術(shù)相同，在 此不再展開詳細描述。
[0068] 與前述基于APP應(yīng)用的Portal認證方法的實施例相對應(yīng)，本公開還提供了基于 APP應(yīng)用的Portal認證裝置的實施例。
[0069] 本發(fā)明基于APP應(yīng)用的Portal認證裝置的實施例應(yīng)用在圖3所示的接入設(shè)備上。 裝置實施例可以通過軟件實現(xiàn)，也可以通過硬件或者軟硬件結(jié)合的方式實現(xiàn)。以軟件實現(xiàn) 為例，作為一個邏輯意義上的裝置，是通過其所在接入設(shè)備的CPU將非易失性存儲器中對 應(yīng)的計算機程序指令讀取到內(nèi)存中運行形成的。從硬件層面而言，如圖3所示，為本發(fā)明基 于APP應(yīng)用的Portal認證裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖，除了圖3所示的CPU、內(nèi)存以及 非易失性存儲器之外，實施例中裝置所在的設(shè)備通常還可以包括其他硬件。
[0070] 參見圖4,為本發(fā)明基于APP應(yīng)用的Portal認證裝置的實施例框圖，該實施例可以 應(yīng)用在接入設(shè)備上。
[0071] 請參圖4所示，本發(fā)明同時提供一種基于APP應(yīng)用的Portal認證裝置，該方法應(yīng) 用在接入設(shè)備上，該裝置包括：
[0072] 判斷單元510,用于當接收用戶終端向APP應(yīng)用服務(wù)器發(fā)起的TCP三次握手連接請 求后，判斷該連接請求是否已通過Portal認證或者在白名單內(nèi)，若是，則通知轉(zhuǎn)發(fā)單元530 進行后續(xù)處理，否則通知處理單元520進行后續(xù)處理；
[0073] 轉(zhuǎn)發(fā)單元530,用于轉(zhuǎn)發(fā)用戶終端的TCP三次握手連接請求報文，使用戶終端與 APP應(yīng)用服務(wù)器建立TCP連接，以便用戶終端在該APP應(yīng)用中通過內(nèi)嵌的Portal頁面進行 認證；
[0074] 處理單元520，用于仿冒APP應(yīng)用服務(wù)器與用戶終端建立TCP連接；
[0075] 解析單元540,用于接收用戶終端發(fā)送的Http的Get請求報文，解析該報文中的 URL，將APP應(yīng)用服務(wù)器的IP地址加入到白名單內(nèi)，并向用戶終端返回RST報文，通知用戶 終端重新進行TCP三次握手連接。
[0076] 進一步地，處理單元520在仿冒APP應(yīng)用服務(wù)器的同時，進一步存儲用戶終端的識 別信息以及APP應(yīng)用服務(wù)器的IP地址信息；
[0077] 解析單元540解析URL獲取APP應(yīng)用的域名信息后，通知判斷單元510判斷是否 需要將APP應(yīng)用加入白名單內(nèi)，如果是，則根據(jù)處理單元520保存的用戶終端識別信息將所 述域名與APP應(yīng)用服務(wù)器的IP地址關(guān)聯(lián)，并將該APP應(yīng)用服務(wù)器的IP地址加入白名單，而 后發(fā)送RST報文給用戶終端。
[0078] 隨后，用戶終端收到RST報文后重新往對應(yīng)IP地址的APP服務(wù)器發(fā)起三次握手， 由于該APP服務(wù)器的IP地址為白名單規(guī)則，因此接入設(shè)備直接放行，用戶登錄成功。進一 步地，用戶登錄成功后，在APP應(yīng)用中打開Portal服務(wù)器的公眾號，內(nèi)嵌的Portal服務(wù)器 推出認證頁面，用戶終端通過輸入用戶名和密碼認證后可正常訪問互聯(lián)網(wǎng)資源，即表示用 戶終端可以正常上網(wǎng)了。
[0079] 本發(fā)明提出一種基于APP應(yīng)用的Portal認證方法及其裝置，通過安裝在用戶終端 的熱門APP應(yīng)用中內(nèi)嵌Portal認證，從而利用在APP應(yīng)用中推廣公眾號的形式，提高企業(yè) 競爭力，推廣企業(yè)形象。
[0080] 以上結(jié)合附圖實施例對本發(fā)明進行了詳細說明，本領(lǐng)域中普通技術(shù)人員可根據(jù)上 述說明對本發(fā)明做出種種變化例。因而，實施例中的某些細節(jié)不應(yīng)構(gòu)成對本發(fā)明的限定，本 發(fā)明將以所附權(quán)利要求書界定的范圍作為本發(fā)明的保護范圍。
【權(quán)利要求】
1. 一種基于APP應(yīng)用的Portal認證方法，應(yīng)用于接入設(shè)備上，其特征在于，所述方法包 括： 接收用戶終端向APP應(yīng)用服務(wù)器發(fā)起的TCP三次握手連接請求，判斷該連接請求是否 已通過Portal認證或者在白名單內(nèi)，若是，則轉(zhuǎn)發(fā)所述用戶終端的TCP三次握手連接請求 報文，使所述用戶終端與所述APP應(yīng)用服務(wù)器建立TCP三次握手連接，以便所述用戶終端在 該APP應(yīng)用中通過內(nèi)嵌的Portal頁面進行認證；否則，仿冒所述APP應(yīng)用服務(wù)器與所述用 戶終端建立TCP三次握手連接； 接收所述用戶終端發(fā)送的Http的Get請求報文，解析該報文中的URL，將所述APP應(yīng)用 服務(wù)器的IP地址并將其加入到白名單內(nèi)，向用戶終端返回RST報文，通知用戶終端向所述 APP應(yīng)用服務(wù)器重新發(fā)起TCP三次握手連接請求。
2. 根據(jù)權(quán)利要求1所述的認證方法，其特征在于，在用戶終端向APP應(yīng)用服務(wù)器發(fā)起 TCP三次握手連接請求之前還包括： 所述用戶終端向DNS服務(wù)器發(fā)起所述APP應(yīng)用的DNS請求，獲取該APP應(yīng)用服務(wù)器的 IP地址。
3. 根據(jù)權(quán)利要求1所述的認證方法，其特征在于，用戶終端向APP應(yīng)用服務(wù)器發(fā)起的 TCP三次握手連接請求認證通過后，所述用戶終端在APP應(yīng)用中通過內(nèi)嵌的Portal頁面進 行認證的具體步驟包括： 所述用戶終端在APP應(yīng)用中打開Portal服務(wù)器的公眾號，內(nèi)嵌的Portal服務(wù)器推出 認證頁面，所述APP用戶終端通過認證后可正常訪問互聯(lián)網(wǎng)資源。
4. 根據(jù)權(quán)利要求3所述的認證方法，其特征在于，所述APP應(yīng)用中的Portal服務(wù)器公 眾號通過所述用戶終端在第一次網(wǎng)頁認證時，通過掃描網(wǎng)頁中內(nèi)嵌廣告推廣公眾號以加入 到公眾號中。
5. 根據(jù)權(quán)利要求1所述的認證方法，其特征在于，所述接入設(shè)備在仿冒所述APP應(yīng)用服 務(wù)器的同時，存儲用戶終端的識別信息以及APP應(yīng)用服務(wù)器的IP地址信息。
6. 根據(jù)權(quán)利要求5所述的認證方法，其特征在于，將所述APP應(yīng)用服務(wù)器的IP地址加 入到白名單內(nèi)，具體包括： 當所述用戶終端發(fā)起Http的Get請求時，所述接入設(shè)備通過解析URL獲取所述APP應(yīng) 用的域名信息，并根據(jù)該域名判斷是否需要將APP應(yīng)用加入白名單內(nèi)，如果是，則根據(jù)保存 的用戶終端識別信息將所述域名與APP應(yīng)用服務(wù)器的IP地址關(guān)聯(lián)，進而將該APP應(yīng)用服務(wù) 器的IP地址加入白名單，而后發(fā)送RST報文給所述用戶終端。
7. -種基于APP應(yīng)用的Portal認證裝置，其特征在于，所述認證裝置包括： 判斷單元，用于當接收用戶終端向APP應(yīng)用服務(wù)器發(fā)起的TCP三次握手連接請求后，判 斷該連接請求是否已通過Portal認證或者在白名單內(nèi)，若是，則通知轉(zhuǎn)發(fā)單元進行處理， 否則通知處理單元進行處理； 轉(zhuǎn)發(fā)單元，用于接收到判斷單元的通知后，轉(zhuǎn)發(fā)用戶終端的TCP三次握手連接請求報 文，使用戶終端與APP應(yīng)用服務(wù)器建立TCP連接，以便用戶終端在該APP應(yīng)用中通過內(nèi)嵌的 Portal頁面進行認證； 處理單元，用于接收到判斷單元的通知后，仿冒APP應(yīng)用服務(wù)器與用戶終端建立TCP連 接； 解析單元，用于接收用戶終端發(fā)送的Http的Get請求報文，解析該報文中的URL，將 APP應(yīng)用服務(wù)器的IP地址加入到白名單內(nèi)，并向用戶終端返回RST報文，通知用戶終端重新 進行TCP三次握手連接。
8. 根據(jù)權(quán)利要求7所述的認證裝置，其特征在于，所述處理單元在仿冒APP應(yīng)用服務(wù)器 的同時，進一步存儲用戶終端的識別信息以及APP應(yīng)用服務(wù)器的IP地址信息。
9. 根據(jù)權(quán)利要求7所述的認證裝置，其特征在于，所述解析單元解析URL獲取所述APP 應(yīng)用的域名信息后，通知判斷單元判斷是否需要將APP應(yīng)用加入白名單內(nèi)，如果是，則根據(jù) 處理單元保存的用戶終端識別信息將所述域名與APP應(yīng)用服務(wù)器的IP地址關(guān)聯(lián)，并將該 APP應(yīng)用服務(wù)器的IP地址加入白名單，而后發(fā)送RST報文給所述用戶終端。
【文檔編號】H04L29/06GK104158808SQ201410409718
【公開日】2014年11月19日 申請日期:2014年8月19日 優(yōu)先權(quán)日:2014年8月19日
【發(fā)明者】徐勇剛 申請人:杭州華三通信技術(shù)有限公司