最好的解決方案
的服務器和客戶端知道一個公鑰和私鑰;只有服務器和客戶端知道私鑰,但每個人都可以知道公鑰......誰在乎他們所知道的。 客戶端創建一個唯一的HMAC(散列),表示它對服務器的請求。它通過結合請求數據(參數和值或者XML/JSON或者它正在計劃發送的任何數據)並將請求數據的blob與私鑰進行散列來完成此操作。 然後,客戶端將HASH發送到服務器,以及它將要發送的所有參數和值。 服務器根據提交的值使用客戶端使用的相同方法獲取請求並重新生成它自己的唯一HMAC(哈希)。 服務器然後比較兩個HMAC,如果它們相等,則服務器信任客戶端並運行請求。
說明一個例子: (於Android假設你正在發送該請求,因爲Android應用程序大多是無會話,他們不能有餅乾或記住哪些用戶已在大二登錄這種情況。當一個請求與它的用戶憑證還需要一起發送)
- 網站哪個請求必須被製成(在這種情況下我使用 本地主機):本地主機:8080/
- URL REST請求X: localhost:8080/REST/books/favorites(假設回答是在 明文間用逗號分隔[Harry Potter,Chandamama, Infinitethoughts,Twilight])。
- 由於用戶X信息必須顯示請求將會像 這樣: 本地主機:8080/REST /用戶名/密碼/書籍/最愛 - 本地主機:8080/REST/X/ABC /書籍/收藏
這裏的問題是用戶名和密碼就可以,因爲他們是純text..so嗅探,更好地在客戶端進行加密,並在服務器端解密。
現在實際的問題出現了,服務器是如何知道是否發送的請求是通過有效的客戶端或不發送...
這種情況的解決方案是生成的散列你URL請求並添加 ,該值在URL的末尾進行散列,然後將請求發送到 服務器。 (就是我們通常說的是校驗)..用烏爾自己生成的校驗 或使用基於Java的哈希生成像SHA1,MD5等
承擔URL請求 本地主機生成的哈希:8080/REST /加密-username/encrypted-Password/books/favorites 是一些哈希字符串adasfsjimnom123123k。因此,將它添加到您的網址
本地主機:8080/REST /加密的用戶名/加密密碼/書籍/收藏/ adasfsjimnom123123k
因此,通過這種方式可以確保Web服務請求。只有當生成的校驗和有效時,服務器纔會提供請求的詳細信息。
使用Curl工具作爲休息消耗客戶端(而不是單獨的java代碼)來測試您的服務。
For Full Reference
不要傳遞憑據通過HTTP。使用HTTPS。 – NoChance
'他們中的許多人,誰?我只想念這個問題嗎? –