(HTTPS)web 项目如何实现https

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>