檢視:[
大字型
中字型
小字型]
近日接到乙個需求，要求一台資源伺服器不僅在可以暴露在公網環境下的同時，還要保證只接受並處理可信的http訪問請求。
需求場景如圖：
為了訪問資源檔案，使用者需要首先訪問某一台frontend server進行使用者身份認證———所有的使用者資訊均由frontend server儲存，frontend server認證通過後返回真實的重定向位址，使用者再根據重定向位址訪問resource server獲取資源檔案。
具體的使用場景正如上面所述，下面是我的思考過程...
重定向位址必須是可信的，即不可以被偽造，必須是由某一台frontend server返回的重定向位址。
為了防止盜鏈或資源被採集，每個frontend server返回的重定向位址應具有時效性。這個可以通過在鏈結位址上增加時間戳實現，但前提是該時間戳不可以被偽造。
最後，在必要的情況下，還可以不去響應某一台frontend server返回的重定向位址，即認為某一台frontend server的重定向位址不可信、該frontend server不可信。這要求resource server能夠及時標示一台frontend server為不可信伺服器，並且該frontend sever伺服器還不可偽造剩餘可信伺服器返回的重定向位址。
以上三點也可以總結為：防止公網使用者偽造url位址，防止不可信frontend server偽造位址，防止過期url位址訪問。
由於resource server需要允許所有的公網使用者訪問，所以不能對ip進行限制，並且一般情況下resouce server也不會與frontend server直接通訊，因此只能通過url的驗證方式。frontend server在生成每個url的過程中中應包括resource server為每乙個frontend server分配的賬戶fsid、金鑰fskey以及記錄當前url生成時間的時間戳fstime。fsid必須明文傳輸，fskey做為加密運算的乙個常量不可以明文傳輸。
可以想到的有如下三種：
resource server收到該請求後
以上三種方法第一種會暴露所有的明文傳遞引數，第二種貌似最方便但卻有被攻破的危險，第三種有可能又會產生效率的問題。
由於沒有進行過相關方面的開發，以上也是對平時了解有限的一些資料的總結，難免考慮不周。各位有更好的方法和建議嗎？
如何修改請求的url位址
可以有兩種方法 一種是採用dispatcher的forward方法，進行內部重定向到新的url位址上 第一中方法可以參見如下網頁 springboot 利用過濾器filter修改請求url位址 實現此方法後，發現有個巨大的坑，並且無法解決。因為我們都採用的是spring boot框架，進行單元測試使...
URL 簡單加密
問題 使用window.open 開啟乙個頁面時如果不對url進行處理，將會把所有的引數完整的顯示在位址列中，會暴露很多資訊。介紹一種簡單的加密方法。解決辦法 1 引數 描述uristring 必需。乙個字串，含有 uri 元件或其他要編碼的文字。uristring 的副本，其中的某些字元將被十六進...
url加密解密
js對文字進行編碼涉及3個函式 escape,encodeuri,encodeuricomponent，相應3個解碼函式 unescape,decodeuri,decodeuricomponent 1 傳遞引數時需要使用encodeuricomponent，這樣組合的url才不會被 等特殊字元截斷。...