(HTTPS)Web 專案如何?https

標籤：blog   http   io   ar   os   使用   java   for   sp   

HTTPS實際是SSL over HTTP, 該協議通過SSL在發送方把未經處理資料進行加密，在接收方解
密，因此，所傳送的資料不容易被網路駭客截獲和破解。本文介紹HTTPS的三種實現方法
。
方法一 靜態超連結
這是目前網站中使用得較多的方法，也最簡單。在要求使用SSL進行傳輸的Web網頁連結
中直接標明使用HTTPS協議，以下是指向需要使用SSL的網頁的超連結：
<a href=“https://192.168.100.100/ok/securePage.jsp”>SSL例子</a>
需要說明的是，在網頁裡的超連結如果使用相對路徑的話，其預設啟用協議與引用該超
連結的網頁或資源的傳輸協議相同，例如在某超連結“https://192.168.100.100/ok/l
ogin.jps”的網頁中包含如下兩個超連結：
<a href=“./bessl/exam.jsp”>SSL連結</a>
<a href=“http://192.168.100.100/notssl/index.jsp”>非SSL連結
那麼，第一個連結使用與“https://192.168.100.100/ok/login.jsp”相同的傳輸協議
HTTPS，第二個連結使用本身所標識的協議HTTP。
使用靜態超連結的好處是容易實現，不需要額外開發。然而，它卻不容易維護管理; 因
為在一個完全使用HTTP協議訪問的Web應用裡，每個資源都存放在該應用特定根目錄下的
各個子目錄裡，資源的連結路徑都使用相對路徑，這樣做是為了方便應用的遷移並且易
於管理。但假如該應用的某些資源要用到HTTPS協議，引用的連結就必須使用完整的路徑
，所以當應用遷移或需要更改URL中所涉及的任何部分如：網域名稱、目錄、檔案名稱等，維護
者都需要對每個超連結修改，工作量之大可想而知。再者，如果客戶在瀏覽器地址欄裡
手工輸入HTTPS協議的資源，那麼所有敏感機密資料在傳輸中就得不到保護，很容易被黑
客截獲和篡改！
方法二 資源訪問限制
為了保護Web應用中的敏感性資料，防止資源的非法訪問和保證傳輸的安全性，Java Serv
let 2.2規範定義了安全約束（Security-Constraint）元件，它用於指定一個或多個We
b資源集的安全約束條件；使用者資料約束（User-Data-Constraint）元件是安全約束元件
的子類，它用於指定在用戶端和容器之間傳輸的資料是如何被保護的。使用者資料約束元
件還包括了傳輸保證（Transport-Guarantee）元件，它規定了客戶機和伺服器之間的通
信必須是以下三種模式之一：None、Integral、Confidential。None表示被指定的Web資
源不需要任何傳輸保證；Integral表示客戶機與伺服器之間傳送的資料在傳送過程中不
會被篡改; Confidential表示資料在傳送過程中被加密。大多數情況下，Integral或Co
nfidential是使用SSL實現。
這裡以BEA的WebLogic Server 6.1為例介紹其實現方法，WebLogic是一個效能卓越的J2
EE伺服器，它可以對所管理的Web資源，包括EJB、JSP、Servlet應用程式設定存取控制
條款。假設某個應用建立在Weblogic Server裡的/mywebAPP目錄下，其中一部分Servle
ts、JSPs要求使用SSL傳輸，那麼可將它們都放在/mywebAPP/sslsource/目錄裡，然後編
輯/secureAPP/Web-INF/web.xml檔案，通過對web.xml的設定可達到對Web使用者實現訪問
控制。
當Web使用者試圖通過HTTP訪問/sslsource目錄下的資源時，Weblogic Server就會尋找we
b.xml裡的訪問約束定義，返回提示資訊：Need SSL connection to access this reso
urce。資源訪問限制與靜態超連結結合使用，不僅繼承了靜態超連結方法的簡單易用性
，而且有效保護了敏感資源資料。然而，這樣就會存在一個問題： 假如Web客戶使用HT
TP協議訪問需要使用SSL的網路資源時看到彈出的提示資訊: Need SSL connection to  
access this resource，大部分人可能都不知道應該用HTTPS去訪問該網頁，造成的後果
是使用者會放棄訪問該網頁，這是Web應用服務提供者不願意看到的事情。
方法三 連結重新導向
綜觀目前商業網站資源資料的互動訪問，要求嚴格加密傳輸的資料只佔其中一小部分，
也就是說在一個具體Web應用中需要使用SSL的服務程式只佔整體的一小部分。那麼，我
們可以從應用開發方面考慮解決方案，對需要使用HTTPS協議的那部分JSPs、Servlets或
EJBs進行處理，使程式本身在接收到訪問請求時首先判斷該請求使用的協議是否符合本
程式的要求，即來訪請求是否使用HTTPS協議，如果不是就將其訪問協議重新導向為HTTPS
，這樣就避免了客戶使用HTTP協議訪問要求使用HTTPS協議的Web資源時，看到錯誤提示
資訊無所適從的情況，這些處理對Web客戶來說是透明的。
實現思想是：首先建立一個類，該類方法可以實現自動引導Web客戶的訪問請求使用HTT
PS協議，每個要求使用SSL進行傳輸的Servlets或JSPs在程式開始時調用它進行協議重定
向，最後才進行資料應用處理。
J2EE提供了兩種連結重新導向機制。第一種機制是RequestDispatcher介面裡的forward()
方法。使用MVC(Model-View-Controller)機制的Web應用通常都使用這個方法從Servlet
轉移請求到JSP。但這種轉向只能是同種協議間的轉向，並不能重新導向到不同的協議。第
二種機制是使用HTTPServletReponse介面裡的sendRedirect()方法，它能使用任何協議
重新導向到任何URL，例如：
BeSslResponse.sendRedirect(“https://192.168.100.100/order”);
此外，我們還需使用到Java Servlet API中的兩個方法：ServletRequest介面中的getS
cheme()，它用於擷取訪問請求使用的傳輸協議；HTTPUtils類中的getRequestUrl()，它
用於擷取訪問請求的URL，要注意的是該方法在Servlet 2.3中已被移到HTTPServletReq
uest介面。
以下是實現協議重新導向的基本步驟：
1. 擷取訪問的請求所使用的協議；
2. 如果請求協議符合被訪問的Servlet所要求的協議，就說明已經使用HTTPS協議了，不
需做任何處理；
3. 如果不符合，使用Servlet所要求的協議(HTTPS)重新導向到相同的URL。
例如，某Web使用者使用HTTP協議訪問要求使用HTTPS協議的資源BeSslServlet，敲入“UR
L：http://192.168.100.100/BeSslServlet”，在執行BeSslServlet時首先使用Proces
sSslServlet．processSsl（）重新導向到https://192.168.100.100/BeSslServlet，然後
BeSslServlet與客戶瀏覽器之間就通過HTTPS協議進行資料轉送。
以上介紹的僅是最簡單的例子，是為了對這種重新導向的方法有個初步的認識。假如想真
正在Web應用中實現，還必須考慮如下幾個問題：
● 在Web應用中常常會用到GET或Post方法，訪問請求的URL中就會帶上一些查詢字串，
這些字串是使用getRequesUrl()時擷取不到的，而且在重新導向之後會丟失，所以必須在
重新導向之前將它們加入到新的URL裡。我們可以使用request.getQueryString()來擷取G
ET的查詢字串，對於Post的Request參數，可以把它們轉換成查詢串再進行處理。
● 某些Web應用請求中會使用對象作為其屬性，必須在重新導向之前將這些屬性儲存在該
Session中，以便重新導向後使用。
● 大多數瀏覽器會把對同一個主機的不同連接埠的訪問當作對不同的主機進行訪問，分用
不同的Session，為了使重新導向後保留使用原來的Session，必須對應用伺服器的Cookie
網域名稱進行相應的設定。
以上問題均可在程式設計中解決。
通過程式自身實現協議重新導向，就可以把要求嚴格保護的那部分資源與其他普通資料從
邏輯上分開處理，使得要求使用SSL的資源和不需要使用SSL的資源各取所需，避免浪費
網站的系統資源。

來源： <http://zhidao.baidu.com/link?url=8QDuuA8qQ7eJ1eFAfJqQapi_JACCb4zq_EjrsqPn3W7BunG1Ee1qziiDjTcKXO9nSUvFyliIPLOvryQzxA6uPtpUignrgoVmbQiFi4y3zfG>                                                                                        

(HTTPS)Web 專案如何?https