https三種實現(xiàn)途徑

千里之行，始于足下。第2頁/共2頁精品文檔推薦https三種實現(xiàn)途徑

HTTPS的三種實現(xiàn)辦法

HTTPS實際是SSLoverHTTP,該協(xié)議經過SSL在發(fā)送方把原始數(shù)據舉行加密，在接收方解密，所以，所傳送的數(shù)據別容易被網絡黑客截獲和破解。本文介紹HTTPS的三種實現(xiàn)辦法。

辦法一靜態(tài)超鏈接

這是目前網站中使用得較多的辦法，也最簡單。在要求使用SSL舉行傳輸?shù)腤eb網頁鏈接中直截了當標明使用HTTPS協(xié)議，以下是指向需要使用SSL的網頁的超鏈接：

SSL例子

需要講明的是，在網頁里的超鏈接假如使用相對路徑的話，其默認啟用協(xié)議與引用該超鏈接的網頁或資源的傳輸協(xié)議相同，例如在某超鏈接“HTTPS://00/ok/login.jps”的網頁中包含如下兩個超鏈接：

SSL鏈接

非SSL鏈接

這么，第一具鏈接使用與“HTTPS://00/ok/login.jsp”相同的傳輸協(xié)議HTTPS，第二個鏈接使用本身所標識的協(xié)議HTTP。

使用靜態(tài)超鏈接的好處是容易實現(xiàn)，別需要額外開辟。但是，它卻別容易維護治理;因為在一具徹底使用HTTP協(xié)議拜訪的Web應用里，每個資源都存放在該應用特定根名目下的各個子名目里，資源的鏈接路徑都使用相對路徑，如此做是為了方便應用的遷移同時易于治理。但如果該應用的某些資源要用到HTTPS協(xié)議，引用的鏈接就必須使用完整的路徑，因此當應用遷移或需要更改URL中所涉及的任何部分如：域名、名目、文件名等，維護者都需要對每個超鏈接修改，工作量之大可想而知。再者，假如客戶在掃瞄器地址欄里手工輸入HTTPS協(xié)議的資源，這么所有敏感機密數(shù)據在傳輸中就得別到愛護，非常容易被黑客截獲和篡改！

辦法二資源拜訪限制

為了愛護Web應用中的敏感數(shù)據，防止資源的非法拜訪和保證傳輸?shù)陌踩?，JavaServlet2.2規(guī)范定義了安全約束（Security-Constraint）元件，它用于指定一具或多個Web資源集的安全約束條件；用戶數(shù)據約束（User-Data-Constraint）元件是安全約束元件的子類，它用于指定在客戶端和容器之間傳輸?shù)臄?shù)據是怎么被愛護的。用戶數(shù)據約束元件還包括了傳輸保證（Transport-Guarantee）元件，它規(guī)定了客戶機和服務器之間的通信必須是以下三種模式之一：None、Integral、Confidential。None表示被指定的Web資源別需要任何傳輸保證；Integral表示客戶機與服務器之間傳送的數(shù)據在傳送過程中不可能被篡改;Confidential表示數(shù)據在傳送過程中被加密。大多數(shù)事情下，Integral或Confidential是使用SSL實現(xiàn)。

這個地方以BEA的WebLogicServer6.1為例介紹事實上現(xiàn)辦法，WebLogic是一具性能卓越的J2EE服務器，它能夠對所治理的Web資源，包括EJB、JSP、Servlet應用程序設置拜訪操縱條款。假設某個應用建立在

WeblogicServer里的/mywebAPP名目下，其中一部分Servlets、JSPs要求使用SSL傳輸，這么可將它們都放在/mywebAPP/sslsource/名目里，然后編輯/secureAPP/Web-INF/web.xml文件，經過對web.xml的設置可達到對Web用戶實現(xiàn)拜訪操縱。

當Web用戶試圖經過HTTP拜訪/sslsource名目下的資源時，WeblogicServer就會查找web.xml里的拜訪約束定義，返回提示信息：NeedSSLconnectiontoaccessthisresource。資源拜訪限制與靜態(tài)超鏈接結合使用，別僅繼承了靜態(tài)超鏈接辦法的簡單易用性，而且有效愛護了敏感資源數(shù)據。但是，如此就會存在一具咨詢題：如果Web客戶使用HTTP協(xié)議拜訪需要使用SSL的網絡資源時看到彈出的提示信息:NeedSSLconnectiontoaccessthisresource，大部分人也許都別懂應該用HTTPS去拜訪該網頁，造成的后果是用戶會放棄拜訪該網頁，這是Web應用服務提供商別情愿看到的情況。

辦法三鏈接重定向

綜觀目前商業(yè)網站資源數(shù)據的交互拜訪，要求嚴格加密傳輸?shù)臄?shù)據只占其中一小部分，也算是講在一具具體Web應用中需要使用SSL的服務程序只占整體的一小部分。這么，我們能夠從應用開辟方面思考解決辦法，對需要使用HTTPS協(xié)議的那部分JSPs、Servlets或EJBs舉行處理，使程序本身在接收到拜訪請求時首先推斷該請求使用的協(xié)議是否符合本程序的要求，即來訪請求是否使用HTTPS協(xié)議，假如別是就將其拜訪協(xié)議重定向為HTTPS，如此就幸免了客戶使用HTTP協(xié)議拜訪要求使用HTTPS協(xié)議的Web資源時，看到錯誤提示信息無所適從的事情，這些處理對Web客戶來講是透明的。

實現(xiàn)思想是：首先創(chuàng)建一具類，該類辦法能夠實現(xiàn)自動引導Web客戶的拜訪請求使用HTTPS協(xié)議，每個要求使用SSL舉行傳輸?shù)腟ervlets或JSPs在程序開始時調用它舉行協(xié)議重定向，最終才舉行數(shù)據應用處理。

J2EE提供了兩種鏈接重定向機制。第一種機制是RequestDispatcher接口里的forward()辦法。使用MVC(Model-View-Controller)機制的Web應用通常都使用那個辦法從Servlet轉移請求到JSP。但這種轉向只能是同種協(xié)議間的轉向，并別能重定向到別同的協(xié)議。第二種機制是使用HTTPServletReponse接口里的sendRedirect()辦法，它能使用任何協(xié)議重定向到任何URL，例如：

BeSslResponse.sendRedirect(“HTTPS://00/order”);

此外，我們還需使用到JavaServletAPI中的兩個辦法：ServletRequest接口中的getScheme()，它用于獵取拜訪請求使用的傳輸協(xié)議；HTTPUtils類中的getRequestUrl()，它用于獵取拜訪請求的URL，要注意的是該辦法在Servlet2.3中已被移到HTTPServletRequest接口。

以下是實現(xiàn)協(xié)議重定向的基本步驟：

1.獵取拜訪的請求所使用的

協(xié)議；

2.假如請求協(xié)議符合被拜訪的Servlet所要求的協(xié)議，就講明差不多使用HTTPS協(xié)議了，別需做任何處理；

3.假如別符合，使用Servlet所要求的協(xié)議(HTTPS)重定向到相同的URL。

例如，某Web用戶使用HTTP協(xié)議拜訪要求使用HTTPS協(xié)議的資源BeSslServlet，敲入“URL：HTTP://00/BeSslServlet”，在執(zhí)行BeSslServlet時首先使用ProcessSslServlet．processSsl（）重定向到HTTPS://00/BeSslServlet，然后BeSslServlet與客戶掃瞄器之間就經過HTTPS協(xié)議舉行數(shù)據傳輸。

以上介紹的僅是最簡單的例子，是為了對這種重定向的辦法有個初步的認識。如果想真正在Web應用中實現(xiàn)，還必須思考如下幾個咨詢題：

●在Web應用中常常會用到GET或Post辦法，拜訪請求的URL中就會帶上一些查詢字串，這些字串是使用getRequesUrl()時獵取別到的，而且在重定向之后會丟失，因此必須在重定向之前將它們加入到新的URL里。我們能夠使用request.getQueryString()來獵取GET的查詢字串，關于Post的Request參數(shù)，能夠把它們轉換成查詢串再舉行處理。

●某些Web應用請求中會使用對象作為其屬性，必須在重定向之前將這些屬性保存在該Session中，以便重定向后使用。

●大多數(shù)掃瞄器會把對同一具主機的別同端口的拜訪當作對別同的主機舉行拜訪，分