本發(fā)明涉及服務(wù)器消息推送技術(shù)領(lǐng)域，具體涉及一種應(yīng)用消息的安全推送系統(tǒng)及方法。

背景技術(shù)：

服務(wù)器與客戶端之間的通信過程中，消息推送的必須的，現(xiàn)有技術(shù)中，大部分通過一個客戶端的應(yīng)用服務(wù)器把消息體發(fā)送給推送服務(wù)器，再由推送服務(wù)器把所述消息體推送給另一個客戶端的推送方式進(jìn)行消息推送。這種通信方式中，消息體的安全性依賴于推送服務(wù)器，即第三方服務(wù)器，存在一定的消息安全隱患?；谙踩紤]，本發(fā)明提供一種應(yīng)用消息的安全推送方法。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明提供一種應(yīng)用消息的安全推送系統(tǒng)及方法，通過第二客戶端解析接收到的消息通知后向應(yīng)用服務(wù)器獲取相應(yīng)的消息體，使得消息體僅在第一客戶端的應(yīng)用服務(wù)器中存儲，無需推送服務(wù)器直接將消息體推送至第二客戶端，保證了消息體的安全性，實(shí)現(xiàn)了消息體的安全推送。

為了解決上述技術(shù)問題，本發(fā)明所采取的技術(shù)方案為：

本發(fā)明一方面提供一種應(yīng)用消息的安全推送系統(tǒng)，包括第一客戶端、應(yīng)用服務(wù)器、推送服務(wù)器、第二客戶端；

所述第一客戶端用于向應(yīng)用服務(wù)器上傳消息體；

所述應(yīng)用服務(wù)器用于通過調(diào)用自身API接口向推送服務(wù)器發(fā)送所述消息體對應(yīng)的通知消息；

所述推送服務(wù)器用于將接收到的通知消息發(fā)送給第二客戶端；

所述第二客戶端用于解析所述通知消息，并向應(yīng)用服務(wù)器發(fā)送HTTP請求；

所述應(yīng)用服務(wù)器還用于根據(jù)HTTP請求向第二客戶端返回相應(yīng)的消息體。

具體地，所述API接口利用MQTT協(xié)議或XMPP協(xié)議向推送服務(wù)器發(fā)送通知消息。

具體地，所述推送服務(wù)器為MQTT服務(wù)器或XMPP服務(wù)器。

具體地，所述通知消息的消息內(nèi)容包括消息體動作類型、消息體名稱及格式類型。

本發(fā)明另一方面提供一種應(yīng)用消息的安全推送方法，包括如下步驟：

S1：第一客戶端向應(yīng)用服務(wù)器上傳消息體；

S2：所述應(yīng)用服務(wù)器調(diào)用自身API接口向推送服務(wù)器發(fā)送所述消息體對應(yīng)的通知消息；

S3：所述推送服務(wù)器將接收到的通知消息發(fā)送給第二客戶端；

S4：第二客戶端解析所述通知消息后，向應(yīng)用服務(wù)器發(fā)送HTTP請求；

S5：應(yīng)用服務(wù)器根據(jù)HTTP請求向第二客戶端返回相應(yīng)的消息體。

具體地，所述推送服務(wù)器與第一客戶端或第二客戶端采用持久連接方式進(jìn)行連接。

具體地，所述第二客戶端通過HTTP請求的GET方法從應(yīng)用服務(wù)器中下載消息體。

本發(fā)明提供一種應(yīng)用消息的安全推送系統(tǒng)及方法，所述應(yīng)用服務(wù)器通過將存儲的消息體對應(yīng)的消息通知經(jīng)推送服務(wù)器推送至第二客戶端的推送方式，使得第二客戶端解析接收到的消息通知后向應(yīng)用服務(wù)器獲取相應(yīng)的消息體，完成消息體的推送，使得消息體僅在第一客戶端的應(yīng)用服務(wù)器中存儲，而沒有經(jīng)過推送服務(wù)器把消息體推送至第二客戶端，所述推送服務(wù)器推送的僅僅是消息體對應(yīng)的消息通知，保證了消息體的安全性，實(shí)現(xiàn)了消息體的安全推送；解決了現(xiàn)有技術(shù)中采用推送服務(wù)器推送消息體存在的消息安全隱患。另一方面，本發(fā)明還適用于背景技術(shù)中提到的采用推送服務(wù)器推送消息體的情況，當(dāng)推送服務(wù)器推送的消息體長度受到限制的消息時(shí)，通過本發(fā)明推送服務(wù)器僅推送消息體對應(yīng)的消息通知的推送方式，使得第二客戶端解析接收到的消息通知后向應(yīng)用服務(wù)器獲取相應(yīng)的消息體，完成消息體的推送。

附圖說明

圖1是本發(fā)明一種應(yīng)用消息的安全推送系統(tǒng)的消息體與通知消息的消息流向圖；

圖2是本發(fā)明一種應(yīng)用消息的安全推送方法的流程圖。

具體實(shí)施方式

下面結(jié)合附圖具體闡明本發(fā)明的實(shí)施方式，附圖僅供參考和說明使用，不構(gòu)成對本發(fā)明專利保護(hù)范圍的限制。

本發(fā)明實(shí)施例一方面提供一種應(yīng)用消息的安全推送系統(tǒng)，包括第一客戶端、應(yīng)用服務(wù)器、推送服務(wù)器、第二客戶端；

所述第一客戶端用于向應(yīng)用服務(wù)器上傳消息體；

所述應(yīng)用服務(wù)器用于通過調(diào)用自身API接口(Application Programming Interface,應(yīng)用程序編程接口)向推送服務(wù)器發(fā)送所述消息體對應(yīng)的通知消息；

所述推送服務(wù)器用于將接收到的通知消息發(fā)送給第二客戶端；

所述第二客戶端用于解析所述通知消息，并向應(yīng)用服務(wù)器發(fā)送HTTP請求；

所述應(yīng)用服務(wù)器還用于根據(jù)HTTP請求向第二客戶端返回相應(yīng)的消息體。

如圖1所示，是本發(fā)明消息體與通知消息的消息流向圖，在本實(shí)施例中，當(dāng)?shù)谝豢蛻舳讼虻诙蛻舳税l(fā)送消息體時(shí)，所述第一客戶端先將消息體上傳至應(yīng)用服務(wù)器中，所述應(yīng)用服務(wù)器通過調(diào)用自身API接口向推送服務(wù)器(即第三方服務(wù)器)僅發(fā)送所述消息體對應(yīng)的通知消息，所述推送服務(wù)器將接收到的通知消息發(fā)送給第二客戶端，所述第二客戶端解析所述通知消息后，向應(yīng)用服務(wù)器發(fā)送HTTP請求，應(yīng)用服務(wù)器根據(jù)所述HTTP請求向第二客戶端返回相應(yīng)的消息體，以完成消息體的推送。例如，第一客戶端向應(yīng)用服務(wù)器上傳的消息體為圖片abc.jpg時(shí)，應(yīng)用服務(wù)器調(diào)用自身API接口向推送服務(wù)器發(fā)送所述消息體對應(yīng)的通知消息：{”action“:”uploadphoto”,”name”:abc.jpg”}，

所述推送服務(wù)器將接收到的上述通知消息發(fā)送給第二客戶端后，所述第二客戶端解析所述通知消息即可獲知應(yīng)用服務(wù)器中保存有圖片abc.jpg，所述第二客戶端通過HTTP請求的GET方法從應(yīng)用服務(wù)器中下載消息體，具體地，所述HTTP請求的GET方法為用“？”分割下載路徑URL與傳輸數(shù)據(jù)，參數(shù)之間以“&&”連接傳輸參數(shù)，如：messagee.type？action＝downloadphoto&&name＝abc.jpg。

在本實(shí)施例中，優(yōu)選地，所述API接口利用MQTT(Message Queuing Telemetry Transport，消息隊(duì)列遙測傳輸)協(xié)議或XMPP(Extensible Messaging and Presence Protocol，可擴(kuò)展通訊和表示協(xié)議)協(xié)議向推送服務(wù)器發(fā)送通知消息。所述MQTT協(xié)議或XMPP協(xié)議均為即時(shí)通訊協(xié)議。

在本實(shí)施例中，優(yōu)選地，所述推送服務(wù)器為MQTT服務(wù)器或XMPP服務(wù)器，所述推送服務(wù)器利用MQTT協(xié)議或XMPP協(xié)議向第二客戶端發(fā)送通知消息。

在本實(shí)施例中，優(yōu)選地，所述通知消息的消息內(nèi)容包括消息體動作類型、消息體名稱及格式類型。如通知消息{“action:“uploadphoto”,“name”:abc.jpg”}的消息體動作類型為“uploadphoto”、消息體名稱及格式類型abc.jpg。

因此，所述消息體僅在應(yīng)用服務(wù)器中存儲，而未經(jīng)過推送服務(wù)器把消息體推送至第二客戶端，所述推送服務(wù)器推送的僅僅是消息體對應(yīng)的消息通知，保證了消息體的安全性，實(shí)現(xiàn)了消息體的安全推送；解決了現(xiàn)有技術(shù)中采用推送服務(wù)器推送消息體存在的消息安全隱患。

上述為本發(fā)明的一種實(shí)施方式，本發(fā)明還適用于背景技術(shù)中提到的采用推送服務(wù)器推送消息體的情況，當(dāng)背景技術(shù)中提到的推送服務(wù)器(即第三方服務(wù)器)遇到推送的消息體長度受到限制時(shí)，通過本發(fā)明推送服務(wù)器僅推送消息體對應(yīng)的消息通知的推送方式，使得第二客戶端解析接收到的消息通知后向應(yīng)用服務(wù)器獲取相應(yīng)的消息體，即可完成消息體的推送。

本發(fā)明實(shí)施例另一方面提供一種應(yīng)用消息的安全推送方法，如圖2所示，包括如下步驟：

S1：第一客戶端向應(yīng)用服務(wù)器上傳消息體；

S2：所述應(yīng)用服務(wù)器調(diào)用自身API接口向推送服務(wù)器發(fā)送所述消息體對應(yīng)的通知消息；

S3：所述推送服務(wù)器將接收到的通知消息發(fā)送給第二客戶端；

S4：第二客戶端解析所述通知消息后，向應(yīng)用服務(wù)器發(fā)送HTTP請求；

S5：應(yīng)用服務(wù)器根據(jù)HTTP請求向第二客戶端返回相應(yīng)的消息體。

在本實(shí)施例中，優(yōu)選地，所述推送服務(wù)器與第一客戶端或第二客戶端采用持久連接方式進(jìn)行連接，使得通知消息具有良好的實(shí)時(shí)性。需要說明的是，第一客戶端與第二客戶端均為應(yīng)用服務(wù)器的客戶端，將所述客戶端命名為第一客戶端與第二客戶端僅僅是為了說明消息體推送的流程中包括向應(yīng)用服務(wù)器上傳消息體的第一客戶端和從應(yīng)用服務(wù)器中下載消息體的第二客戶端。

在本實(shí)施例中，優(yōu)選地，在本實(shí)施例中，所述第二客戶端通過HTTP請求的GET方法從應(yīng)用服務(wù)器中下載消息體。在其它實(shí)施例中，也可以使用HTTP請求的POST方法從應(yīng)用服務(wù)器中下載消息體。

以上所揭露的僅為本發(fā)明的較佳實(shí)施例，不能以此來限定本發(fā)明的權(quán)利保護(hù)范圍，因此依本發(fā)明申請專利范圍所作的等同變化，仍屬本發(fā)明所涵蓋的范圍。