CN101753606B - 一种实现web反向代理的方法 - Google Patents
一种实现web反向代理的方法 Download PDFInfo
- Publication number
- CN101753606B CN101753606B CN 200810227971 CN200810227971A CN101753606B CN 101753606 B CN101753606 B CN 101753606B CN 200810227971 CN200810227971 CN 200810227971 CN 200810227971 A CN200810227971 A CN 200810227971A CN 101753606 B CN101753606 B CN 101753606B
- Authority
- CN
- China
- Prior art keywords
- request
- url
- reverse proxy
- address
- sslvpn
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明提供一种实现WEB反向代理的方法，其中，当用户端在浏览器的书签栏或者界面输入框下输入的第一条WEB反向代理处理请求后，包括下列步骤：客户端发送HTTP/HTTPS请求，该请求的统一资源定位符URL中包含反向代理服务器SSLVPN的地址、被访问的后台服务器的地址以及被访问的后台服务器的资源路径；反向代理服务器SSLVPN截获到上述请求后，提取出被访问的后台服务器地址和资源路径，正常转发请求。本发明中所有实现都是对于HTTP请求，响应头进行加工处理，没有进行任何HTML页面内部的替换，通过格式化的URL，可以在Web服务器上面高效的完成相对URL处理，以及基于重定向的绝对URL格式处理。
Description
技术领域
本发明涉及WEB代理技术，特别涉及一种实现WEB反向代理的方法。
背景技术
在现有的超文本传输协议(Hyper Text Transfer Protocol，HTTP)请求过程可以如下：
本地客户端连接上远程HTTP服务器www.sina.com.cn，然后客户端发送下面的字符串给服务器：
POST /iframe/2008/weather/110100.html HTTP/1.1
Host：www.sina.com.cn
Referer：http://news.sina.com.cn/iframe/2008/weather/jump_new.html
Cookie：vjuids＝20c08e420.11bc93ee742.0.35cc680c38f4e；
vjlast＝1226753330；SINAGLOBAL＝220.181.35.250.92791219544751236；
SINAPUID＝220.181.34.147.306481219848274604；
SSCSum＝1；SINA_NEWS_CUSTOMIZE_city＝％u5317％u4EAC
user＝％61％66％61％66％61％66&passwrod＝％66％61％73％66％61％73％66％61％73％66％61
在上面的请求中，有如下几项需要说明：
/iframe/2008/weather/110100.html，请求的URI，也可直接称为统一资源定位符(Uniform/Universal Resource Locator，URL)表示本请求要获取的目标服务器中相应资源的路径，也被称为网页地址，是因特网上标准的资源的地址(Address)。比如http://www.sina.com.cn/news/33.html，其中后半部份/news/33.html有时候也被称之为URI，也可以笼统的称之为URL。本申请中的URI和URL为同一指定。
POST作为HTTP协议发送是选用的方法类型，如果采用该类型，表示用户要提交数据到服务器，当前例子的数据就是最后的一部分user＝％61％66％61％66％61％66&passwrod＝％66％61％73％66％61％73％66％61％73％66％61，该字段可以选择的值还有GET、PUT等，但是GET方法是最常用的，如果选用GET方法，则表示客户端仅仅想获取当前路径的资源，后面的数据部分则不应该发送。
Referer表示发送当前资源时候的参考路径，也就是说用户知晓当前资源路径的来源地址，比如该请求中
Referer：http://news.sina.com.cn/iframe/2008/weather/jump_new.html
表示http://news.sina.com.cn/iframe/2008/weather/jump_new.html中包含了/iframe/2008/weather/110100.html的链接，所以客户端才可以顺利的找到/iframe/2008/weather/110100.html并且发出访问请求。
www.sina.com.cn服务器收到上面的请求以后，发送下面的回应给客户端：
HTTP/1.0 302Moved
Server：Apache/2.0.63(Unix)
Location：http://www.sina.com.cn/php/34342.html
Connection：close
Content-Type：text/html；charset＝iso-8859-1
<！DOCTYPE HTML PUBLIC″-//IETF//DTD HTML2.0//EN″>
<html><head>
<title>302Moved</title>
</head><body>
<h1>Moved</h1>
<p>The document has moved
<a href＝″http://www.sina.com.cn/php/34342.html″>here</a>.</p>
</body>
</html>
在上面的响应中，第一行的响应状态码302表示这是一个临时重定向，表示服务器要求浏览器客户端重新访问一个新的地址，新地址放在响应头Location，比如本响应中服务器要求客户端重新访问地址http://www，sina.com.cn/php/34342.html。
作为HTTP协议的回应，一般均为HTML页面，当然有时候也包含图片、音频等，下面是一个HTML页面样例：
<html>
<body>
<a href＝″/abs.html″>abs</a>
<img src＝″images/3.jpg></img>
</body>
</html>
上面的样例中，例如页面里的链接标记为A、图片标记为IMG、其他比如提交表单的FORM等均为本文关注的标记或标签(TAG)，而链接标记A中的/abs.html为绝对URL，IMG里面的imags/3.jpg为相对URL。
通常的代理服务器，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器，并将本来要直接发送到Web服务器上的HTTP请求发送到代理服务器中。由于外部网络上的主机并不会配置并使用这个代理服务器，普通代理服务器也被设计为在Internet上搜寻多个不确定的服务器，而不是针对Internet上多个客户机的请求访问某一个固定的服务器，因此普通的Web代理服务器不支持外部对内部网络的访问请求。当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。此时代理服务器对外就表现为一个Web服务器，外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于，这个服务器没有保存任何网页的真实数据，所有的静态网页或者CGI程序，都保存在内部的Web服务器上。因此对反向代理服务器的攻击并不会使得网页信息遭到破坏，这样就增强了Web服务器的安全性。
然而，一般的反向代理服务器都存在很大的弊病，主要分为两种情形：
当代理服务器不改变WEB响应页面的内容的实现，这种情况下，一个外部反向代理服务器只能支持页面无绝对URL链接的网站，比如，如果返回的页面中包含一个链接http://internal.server.com./abc.GIF，则用户访问就会失败。
第二种情况，有些实现中，将所有不符合要求的链接URL全部替换为其定义格式的URL，这样在外面就可以方便的访问，但是这种方式最大的问题就是带来了很大的性能问题，在不必要的情况下作出替换，是得不偿失的。
发明内容
本发明的目的在于，提供一种实现WEB反向代理的方法。
本发明的实现WEB反向代理的方法，其中，当用户端在浏览器的书签栏或者界面输入框下输入的第一条WEB反向代理处理请求后，包括下列步骤：
客户端发送HTTP/HTTPS请求，该请求的统一资源定位符URL中包含反向代理服务器SSLVPN的地址、被访问的后台服务器的地址以及被访问的后台服务器的资源路径；
反向代理服务器SSLVPN截获到上述请求后，提取出被访问的后台服务器地址和资源路径，正常转发请求。
另外，可以包括下列步骤：
当用户访问到WEB反向代理后端的页面以后，再通过浏览器中的HTML页面点击而发出请求；
该请求中的HTML的标记或标签中的统一资源定位符类型属性被赋值为相对路径或绝对路径。
其中，在所述统一资源定位符类型属性被赋值为相对路径时，浏览器在处理该请求前，将按照当前浏览网页作为基准，然后拼接出本请求的统一资源定位符。
其中，在所述统一资源定位符类型属性被赋值为绝对路径时，浏览器在处理该请求前，将直接发送请求的URL，该URL不符合WEB反向代理的交互接口规范，但附带了符合该交互接口规范的Referer请求头；根据HTTP协议规范浏览器将当前请求的父URL使用Referer请求头带到当前请求中；反向代理服务器SSLVPN根据这两项信息判定出被访问的后台服务器地址和资源路径，以正常转发请求。
其中，在该请求为使用GET类型方法的情况下，在进行转发之前，包括下列步骤：
向客户端发送一个HTTP 302临时重定向，该重定向将改变浏览器的当前访问地址，同时在重定向的请求中包含了SSLVPN本身的地址，后台服务器的地址，后台服务器的资源路径。当客户端重新发送上述经过重定向的请求以后，进行正常转发。
进一步地，在该请求为使用POST类型方法的情况下，在进行转发之前，可以包括下列步骤：
在发送重定向请求时，先发送一个保存在SSLVPN中的文件索引，在浏览器重新请求该索引时，再重新拼接出要访问的后台资源而进行转发，同时该重定向的索引格式符合预定的URL格式。
其中，所述URL格式为：协议http或者https：//反向代理服务器地址/WF/后台WEB服务器主机地址/后台协议类型/后台WEB服务器资源路径。
进一步地，在进行转发时，外部系统添加访问控制的控制点，即与AAAA系统结合，所述AAAA系统包括：认证Authentication：验证用户的身份与可使用的网络服务；授权Authorization：依据认证结果开放网络服务给用户；访问控制Access Control，根据授权对于相关资源做出是否允许访问；计帐Accounting：记录用户对各种网络服务的用量，并提供给计费系统。
本发明的有益效果是：依照本发明的实现WEB反向代理的方法，解决反向代理服务器正确标识每个请求的目的内部WEB服务器地址，目的请求协议(HTTP/HTTPS)、方法类型(GET/POST)、以及目的资源的正确路径，从而做到正常转发；在相对URL请求的情况下通过定义的规范化URL以及浏览器本身的内在特性完成客户端正确识别目标URL的；而在绝对URL请求的情况下则是通过交互(重定向)来完成URL重新调整。本发明中所有实现都是对于HTTP请求，响应头进行加工处理，没有进行任何HTML页面内部的替换，无论是格式化的URL，还是相对URL处理，还是基于重定向的绝对URL格式处理，均可以在Web服务器上面高效的完成。
附图说明
图1为本发明的初始请求处理流程示意图；
图2为本发明的绝对URL下的GET类型请求处理过程示意图；
图3为用户通过local.sslvpn.com访问后台资源服务器remotehost里面的相关页面的示意图；
图4为本发明的绝对URL下的POST类型请求处理过程示意图。
具体实施方式
以下，参考附图1～4详细描述本发明的实现WEB反向代理的方法。
任何要从客户端访问的后台Web服务器资源，都要经过反向代理服务器，这样，客户端发送的任何有效访问请求URL里面不但包含代理服务器的地址，同时也必须包含后台服务器的地址和路径，如表1所示的URL格式为本发明使用的格式化请求：
表1
| 协议(http或者https) | :// | 反向代理服务器地址 | WF | 后台Web服务器主机地址 | 后台协议或类型 | 后台Web服务器资源路径 |
例如：
https://www.proxy.com/wf/192.168.2.3/0/images/4.jpg
解释如表2所示：
表2
| 协议 | http或者https，上面例子中为http |
| 反向代理服务器地址 | 表示中间的反向代理服务器地址，所有要访问后台资源的请求都必须通过该地址转发上面例子中为www.proxy.com |
| WF | 这里只是个前缀，表示当前请求是符合本文定义的反向代理请求格式，代理服务器可以根据当前的格式进行解析处理 |
| 后台Web服务器主机地址 | 比如本例子中的192.168.2.3 |
| 后台协议或类型 | 一般选0-4的一个数字0，后台资源为普通HTTP请求1，后台资源为普通HTTPS请求2，该请求中的“后台Web服务器资源路径”里面指向了在反向代理服务器中存储过的数据，根据这些数据，可以重新构造请求，转发到后台，此处为http请求3，同2，但是此时为HTTPS请求上面里中为0表示是个普通HTTP请求 |
| 后台Web服务器资源路径 | 以/开头的后台资源路径，去掉前面的主机地址，比如本例子中的/images/4.jpg如果后台协议或类型里面的值为2或者3，则此路径包含一个指向代理服务器里面的一个数据位置。 |
根据上表，可以看出上面的例子的意思为：
通过www.proxy.com使用普通的http方式访问资源：http://192.168.2.3/images/4.jpg。
下面将描述该技术的实现步骤：
首先，用户端在浏览器的书签栏或者界面输入框下输入的第一条WEB反向代理处理请求。如图1所示，为初始请求处理流程。
从图中可以看出，交互过程被划分为3个实体：浏览器、反向代理服务器(以下简称SSLVPN)、后台WEB服务器。图1中中间两条竖线里面的内容是本子系统运行的过程。
客户端发送HTTP/HTTPS请求，该请求的URL中包含了SSLVPN的地址，同时包含了被请求的后台服务器的地址，被访问的后台服务器的资源路径。
SSLVPN截获到上述请求后，提取出被访问的后台服务器地址和资源路径，正常转发请求。
值得注意的是，在作转发的时候，外部系统可以在此处添加访问控制等控制点，也就是说和AAAA系统完美结合。其中，AAAA系统包括：认证(Authentication)：验证用户的身份与可使用的网络服务；授权(Authorization)：依据认证结果开放网络服务给用户；访问控制(Access Control)，根据授权对于相关资源做出是否允许访问；计帐(Accounting)：记录用户对各种网络服务的用量，并提供给计费系统。
其次，当用户访问到WEB反向代理后端的页面以后，再通过浏览器中的HTML页面点击而发出请求。
其中，该请求一般为某些HTML的TAG，比如A、IMG等的某些URI类型的属性被赋值为相对路径或绝对路径。
对于相对路径而言，浏览器在处理这些请求前，将按照当前浏览网页作为基准，然后拼接出本请求的URL，一般来讲，拼接出来的URL格式和上述的初始请求处理流程相同。
比如下面的例子，用户通过浏览器访问页面：
https://sslvpn.topsec.com.cn/wf/192.168.1.4/0/php/show.php，即用户要通过代理服务器sslvpn.topsec.com.cn访问http://192.168.1.4/php/show.php，服务器收到请求以后发回回应HTML页面
<html>
<body>
<img src＝″images/3.jpg></img>
<a href＝”./login/login.php”>登陆</a>
</body>
</html>
上面的回应页面中包含了一个图片和一个超链接，两个均为相对路径，要求访问当前路径下的images下面的3.jpg以及当前路径下的login目录下的login.php；而当前目录是/php，所以很自然被访问的图片和超链接的路径为
https://sslvpn.topsec.com.cn/wf/192.168.1.4/0/php/images/3.jpg，
https://sslvpn.topsec.com.cn/wf/192.168.1.4/0/php/login/login.php
该处理巧妙地利用了Web浏览器的内置特性来确定当前页面里面包含的TAG标签的具体路径。
另外，对于绝对路径而言，浏览器在处理这些请求前，将直接发送请求的URL(不符合WEB反向代理的交互接口)，但是同时附带了Referer请求头，而该请求头本身却符合接口规范，该种方式的请求流程如下：用户发出HTTP/HTTPS请求，请求的URL为https://wwwlocal.sslvpn.com/dir/12.html，可以看出，这个URL没有包含后台WEB服务器的主机地址，如果发送到SSLVPN网关上，SSLVPN网关无法获知要访问的后台服务器地址，但是根据HTTP协议规范，此时浏览器会将其上一次访问过的URL(也就是当前请求的父URL)使用Referer请求头带到当前请求中，此时SSLVPN网关就可以根据这两项信息判定出需要访问的后台服务器地址和资源路径。
但是在上面的过程中，即使SSLVPN网关判定出了被访问的后台服务器地址和资源路径以后，也不可以直接转发，接收回应并发送给客户端，因为如果这样，浏览器的地址栏上面的当前URL并没有变化，仍然为https://local.sslvpn.com/dir/12.html，这势必影响到了由该请求回应的HTML页面中的其他相对链接的后续访问，比如如果有个链接<AHREF＝”./c.html”>link c</A>，这个时候，该链接相对的路径参照物就是https://local.sslvpn.com/dir/12.html，如果是这样，后续访问中就会丢失后台服务器的地址，此时转发功能就出现了异常。
为了解决上述的转发异常问题，引入重定向机制，此时并不急于转发，而是向客户端发送一个HTTP302临时重定向，该重定向将改变浏览器的当前访问地址，同时在重定向的请求中包含了SSLVPN本身的地址，后台服务器的地址，后台服务器的资源路径。当客户端重新发送上述经过重定向的请求以后，进行正常转发。转发前可以访问控制。
上面的处理过程对于使用GET类型方法的请求工作非常完美，但是如果遇到POST类型就需要额外的工作，如果遇到POST类型的请求，则在发送重定向请求的时候，不要直接发送包含后台服务器地址的拼接URL，而是发送一个保存在SSLVPN中的文件的索引，等浏览器重新请求该索引的时候再重新拼接出要访问的后台资源而进行转发，同时该重定向的索引的格式也符合本文定义的URL格式化规范。
依照上述过程，就可以保证在出现绝对URL时候不会出现路径坏死现象。
下面分别结合实际例子分别列出GET和POST类型方法下的处理过程。
在介绍例子之前，下面给出例子中的网络拓扑图，如图3所示，用户通过local.sslvpn.com访问后台资源服务器remotehost里面的相关页面，首先看一个GET类型请求处理的过程：
本流程的前提是用户已经成功访问过一个符合本文前面描述的格式化URL，这里假定用户刚刚通过
local.sslvpn.com访问过http://remotehost/some.html，用户实际访问的URL为https://local.sslvpn.com/wf/remotehost/0/some.html，该URL符合上面描述的URL格式要求。用户访问https://local.sslvpn.com/wf/remotehost/0/some.html的回应为
<html>
<body>
<P>Hello，World</P>
<img src＝″images/3.jpg></img>
<ahref＝”/2.html”>点击这里</a>
</body>
</html>
上述回应中如果用户点击了“点击这里”，而该标签对应的地址/2.html是一个以/开头的绝对路径，浏览器将认为用户需要访问的地址为https://local.sslvpn.com/2.html，如果直接访问该URL，显然是不可能获取到相应的资源，因为该页面其实是remotehost返回来的。如下所示，用户访问2.html页面的时候，仍然发送的是https://local.sslvpn.com/2.html，但是因为用户是在https://local.sslvpn.com/wf/remotehost/0/some.html页面中点击的，而该页面的URL将被设定为/2.html访问时候的Referer请求头。浏览器将发送下面请求给localhost.sslvpn.com：
GET/2.html HTTP/1.1
User-Agent：Mozilla/5.0(Windows；U；...
Referer：https://local.sslvpn.com/wf/remotehost/0/some.html
Host：192.168.1.39
local.sslvpn.com收到该请求后根据请求里面的URL/2.html和Referer中的相关信息，可以推测出用户想通过local.sslvpn.com访问http://remotehost/2.html，而访问该资源符合规范的URL格式应该为https://local.sslvpn.com/wf/remotehost/0/2.html，这个URL中的0表示使用GET方式(不发送任何附加数据)访问http服务器，之所以知道该资源是HTTP也是因为Referer中的some.html本身的值也为0。
既然知道用户真正要访问的URL，本来可以直接转发到后台，然后获取真实内容发送给用户，但是这里不能这样直接转发，因为如果直接转发，则当前页面会很顺利返回给客户端，但是当前后台资源服务器的相关信息就会完全丢失，用户只会看见自己访问https://local.sslvpn.com/2.html的时候返回了正确的页面，但是从这个页面再重新点击其他的链接的时候，浏览器可能无法知道被点击的资源的确切后台位置，比如如果2.html中包含了一个/introl.html，那么无论introl.html自己的URL还是从它的Referer(2.html)都无法获取应该从那个服务器上面去获取相应的资源。为了解该问题，可以将刚才的https://local.sslvpn.com/wf/remotehost/0/2.html发给浏览器，让浏览器自己重新获取该URL，这个方法的好处是浏览器自己更改了当前页面的URL，以后基于这个URL的访问，比如刚才说的introl.html被访问的时候，其Referer会被正确的标示为符合URL规范格式的：
https://local.sslvpn.com/wf/remotehost/0/2.html。
浏览器重新发送该URL，继续后续的处理，SSLVPN接到上面的URL后，分解出相应的主机remotehost，远程访问协议HTTP-GET(0)，以及被访问的资源/2.html，可以做一些权限判定等操作。
如果符合条件，转发请求到后台，后台获取到内容后，发送给客户端。处理结束，2.html页面中包含的其他链接将会正确的被本模型重新处理。
上面结合例子说明了GET处理，下面的过程描述了POST请求的处理过程：
前面已经介绍了，所谓POST请求，是指在发送获取资源的URL的同时，也要发送相应的额外数据。这些请求一般是通过HTML页面中FORM标签提交时候产生，如下所示，假定用户起先访问了URL：
https://local.sslvpn.com/wf/remotehost/0/some.html
而该URL的回应HTML页面是
<html>
<body>
<P>Hello，World</P>
<img src＝″images/3.jpg></img>
<FORM method＝″post″action＝”/3.html”>
<input type＝″text″name＝″user″>
<input type＝″text″name＝″passwo rd″>
<input type＝″submit″>
</FORM>
</body>
</html>
上述回应中的页面，如果用户点击了提交按钮，就会将该请求发送给对应的地址/3.html是一个以/开头的绝对路径，浏览器将认为用户需要访问的地址为https://local.sslvpn.com/3.html来的。当前该请求和上面描述的GET方式的请求有很大区别，因为在重定向处理中，将会把该POST请求重定向为GET请求(所有的重定向新请求均为GET类型)。如下所示，在本发明中，用户访问3.html页面的时候，仍然发送的是https://local.sslvpn.com/3.html，但是因为用户是在https://local.sslvpn.com/wf/remotehost/0/some.html页面中点击的，而该页面的URL将被设定为/3.html访问时候的Referer请求头。浏览器将发送下面请求给localhost.sslvpn.com：
POST /3.html HTTP/1.1
User-Agent：Mozilla/5.0(Windows；U；...
Referer：https://local.sslvpn.com/wf/remotehost/0/some.html
Host：192.168.1.39
User＝abc&password＝123456
local.sslvpn.com收到该请求后根据请求里面的URL/3.html和Referer中的相关信息，可以推测出用户想通过local.sslvpn.com访问http://remotehost/3.html，同时要发送数据user＝abc&password＝123456给后台资源服务器。和GET方式类似，此时SSLVPN不能直接转发该请求给后台服务器，此时仍然需要发送一个调整URL的重定向。
但是重定向请求只是将调整后的URL本身发送给客户端，其他的信息无法完全告知客户端，比如刚才的应用数据部分。这里本发明用如下方法处理，SSLVPN将客户端发送来的URL/3.html，从Referer头获取的后台主机地址remotehost，应用数据user＝abc＝&password＝123456，以及其他客户端发送来的数据保存在一个临时文件sslvpnXXXXXX中，而给客户端仅仅发送如下的重定向URL：
https://local.sslvpn.com/wf/remotehost/3/topsecwebforwardindex＝sslvpnXXXXXX，该URL格式也符合前面定义的URL格式，这里的3表示是一个POST类型的HTTP请求(如果是4则表示是HTTPS请求)，后面同时加入了保存的文件的索引文件名。
客户端收到该重定向的URL后，重新发起请求，此时客户端发送的是一个GET请求，到了SSLVPN，SSLVPN根据该URL中文件的名称获取到真正的请求，也就是说，SSLVPN会发送http://remotehost/3.html到后台去，当然发送该请求的时候使用POST方法，并且携带应用数据User＝abc＝&password＝123456到后台。
在上面解析完成URL时候，可以加用户权限控制等检查，和AAAA系统对接。和GET请求类似，后面就可以保证正常的应用访问。
综上所述，依照本发明的实现WEB反向代理的方法，解决反向代理服务器正确标识每个请求的目的内部WEB服务器地址，目的请求协议(HTTP/HTTPS)、方法类型(GET/POST)、以及目的资源的正确路径，从而做到正常转发；在相对URL请求的情况下通过定义的规范化URL以及浏览器本身的内在特性完成客户端正确识别目标URL的；而在绝对URL请求的情况下则是通过交互(重定向)来完成URL重新调整；并且在后一情况下，同时包含了两种不尽相同的方式来完成该任务，一个是GET请求的简单重定向方式来实现，另一个POST请求方式，该方式在SSLVPN反向代理服务器上面保存临时数据，然后重新定向，完成正确转发，提高转发效率，在不必要的地方尽量不要作页面内容的替换工作。本发明中所有实现都是对于HTTP请求，响应头进行加工处理，没有进行任何HTML页面内部的替换，无论是格式化的URL，还是相对URL处理，还是基于重定向的绝对URL格式处理，均可以在Web服务器上面高效的完成。
以上是为了使本领域普通技术人员理解本发明，而对本发明所进行的详细描述，但可以想到，在不脱离本发明的权利要求所涵盖的范围内还可以做出其`它的变化和修改，这些变化和修改均在本发明的保护范围内。
Claims (5)
1.一种实现WEB反向代理的方法，其特征在于，当客户端在浏览器的书签栏或者界面输入框下输入的第一条WEB反向代理处理请求后，包括下列步骤：
客户端发送HTTP/HTTPS请求，该请求的统一资源定位符URL中包含反向代理服务器SSLVPN的地址、被访问的后台服务器的地址以及被访问的后台服务器的资源路径；
反向代理服务器SSLVPN截获到上述请求后，提取出被访问的后台服务器地址和资源路径，正常转发请求；
当用户访问到WEB反向代理后端的页面以后，再通过浏览器中的HTML页面点击而发出请求；该请求中的HTML的标记或标签中的统一资源定位符类型属性被赋值为相对路径或绝对路径；
当所述统一资源定位符类型属性被赋值为相对路径时，浏览器在处理该请求时，将按照当前浏览网页作为基准，拼接出本请求的统一资源定位符，并将该统一资源定位符发送至所述反向代理服务器SSLVPN；
当所述统一资源定位符类型属性被赋值为绝对路径时，浏览器在处理该请求时，将该请求的URL，以及该请求的父URL使用的Referer请求头，发送至所述反向代理服务器SSLVPN。
2.如权利要求1所述的实现WEB反向代理的方法，其特征在于，当所述统一资源定位符类型属性被赋值为绝对路径且对应请求为GET类型的请求时，所述方法还包括：
所述反向代理服务器在正常转发对应请求前，向所述客户端发送一个HTTP 302临时重定向请求，该重定向请求将改变浏览器的当前访问地址，所述重定向请求中包含了SSLVPN本身的地址，后台服务器的地址，后台服务器的资源路径；
当所述客户端接收到重定向后的访问地址时，重新发送经过重定向的访问地址至所述反向代理服务器，所述反向代理服务器正常转发对应请求。
3.如权利要求1所述的实现WEB反向代理的方法，其特征在于，当所述统一资源定位符类型属性被赋值为绝对路径且对应请求为POST类型的请求时，所述方法还包括：
所述反向代理服务器在正常转发对应请求前，向所述客户端发送一个HTTP 302临时重定向请求，该重定向请求中包含了一个保存在SSLVPN中的文件索引，并在浏览器重新请求该索引时，重新拼接出要访问的后台资源而进行转发；其中，所述重定向请求中包含的文件索引的格式符合预定的URL格式。
4.如权利要求1至3中任一项所述的实现WEB反向代理的方法，其特征在于，所述URL格式为：
协议htp或者https：//反向代理服务器地址/WF/后台WEB服务器主机地址/后台协议类型/后台WEB服务器资源路径。
5.如权利要求1至3中任一项所述的实现WEB反向代理的方法，其特征在于，在进行转发时，外部系统添加访问控制的控制点，即与AAAA系统结合，所述AAAA系统包括：认证Authentication：验证用户的身份与可使用的网络服务；授权Authorization：依据认证结果开放网络服务给用户；访问控制Access Control，根据授权对于相关资源做出是否允许访问；计帐Accounting：记录用户对各种网络服务的用量，并提供给计费系统。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200810227971 CN101753606B (zh) | 2008-12-03 | 2008-12-03 | 一种实现web反向代理的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200810227971 CN101753606B (zh) | 2008-12-03 | 2008-12-03 | 一种实现web反向代理的方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101753606A CN101753606A (zh) | 2010-06-23 |
| CN101753606B true CN101753606B (zh) | 2013-01-09 |
Family
ID=42480000
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200810227971 Active CN101753606B (zh) | 2008-12-03 | 2008-12-03 | 一种实现web反向代理的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101753606B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106375976A (zh) * | 2015-07-22 | 2017-02-01 | 中国移动通信集团公司 | 一种Web应用计费的方法及装置 |
Families Citing this family (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101873332B (zh) * | 2010-07-15 | 2013-04-17 | 杭州华三通信技术有限公司 | 一种基于代理服务器的web认证方法和设备 |
| CN101917476B (zh) * | 2010-08-11 | 2014-06-25 | 开曼群岛威睿电通股份有限公司 | 超文本传输协议消息处理方法及其客户端系统 |
| CN102447726A (zh) * | 2010-10-15 | 2012-05-09 | 中兴通讯股份有限公司 | 页面访问方法及系统 |
| CN102164178B (zh) * | 2011-03-28 | 2014-04-16 | 华为技术有限公司 | 内容获取方法及客户端 |
| CN102710559B (zh) * | 2012-06-21 | 2016-08-03 | 甘肃省科学技术情报研究所 | 一种反向代理技术实现数字文献资源网关的方法 |
| CN103701760A (zh) * | 2012-09-28 | 2014-04-02 | 中国电信股份有限公司 | 无线局域网Portal认证方法、系统及Portal服务器 |
| CN103916415A (zh) * | 2012-12-28 | 2014-07-09 | 中华电信股份有限公司 | 反向代理系统及其方法 |
| CN103401861B (zh) * | 2013-07-29 | 2016-08-10 | 深信服网络科技（深圳）有限公司 | 代理上网识别方法及装置 |
| US9306912B2 (en) * | 2013-09-03 | 2016-04-05 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Bookmarking support of tunneled endpoints |
| CN106326213A (zh) * | 2015-06-19 | 2017-01-11 | 北京京东尚科信息技术有限公司 | 一种对web站点进行翻译的方法及装置 |
| CN105119986B (zh) * | 2015-08-12 | 2018-04-03 | 国家电网公司 | 一种基于预连接的Web反向代理方法 |
| CN105187406A (zh) * | 2015-08-14 | 2015-12-23 | 安徽新华博信息技术股份有限公司 | 可配置方式的https的中间人监听系统 |
| CN105208100B (zh) * | 2015-08-25 | 2018-11-06 | 联创汽车服务有限公司 | 一种接口数据的处理方法 |
| CN105117347B (zh) * | 2015-09-24 | 2018-09-28 | 上海爱数信息技术股份有限公司 | 测试数据的模拟方法、系统及自动化测试方法、系统 |
| CN107104929B (zh) * | 2016-02-23 | 2021-03-09 | 阿里巴巴集团控股有限公司 | 防御网络攻击的方法、装置和系统 |
| CN106100963A (zh) * | 2016-08-16 | 2016-11-09 | 重庆邮电大学 | 一种基于全文意转换的软件vpn实现方法 |
| CN108965203B (zh) * | 2017-05-18 | 2020-12-29 | 腾讯科技（深圳）有限公司 | 一种资源访问方法及服务器 |
| CN107317845A (zh) * | 2017-06-07 | 2017-11-03 | 北京星网锐捷网络技术有限公司 | 基于Web代理的数据获取方法及装置 |
| CN107277026A (zh) * | 2017-06-29 | 2017-10-20 | 福建天泉教育科技有限公司 | 一种内网访问方法及终端 |
| CN109218368B (zh) * | 2017-07-05 | 2021-09-07 | 北京京东尚科信息技术有限公司 | 实现Http反向代理的方法、装置、电子设备和可读介质 |
| CN107483609B (zh) * | 2017-08-31 | 2018-08-28 | 深圳市迅雷网文化有限公司 | 一种网络访问方法、相关设备和系统 |
| CN107948162A (zh) * | 2017-11-28 | 2018-04-20 | 东莞优闪电子科技有限公司 | 一种使正在接受k12教育的学生绿色上网的方法 |
| CN109067914B (zh) * | 2018-09-20 | 2019-12-13 | 星环信息科技（上海）有限公司 | Web服务的代理方法、装置、设备及存储介质 |
| CN110213348B (zh) * | 2019-05-16 | 2022-05-13 | 中科物栖（北京）科技有限责任公司 | 一种物联网设备控制方法及系统 |
| CN110161870B (zh) * | 2019-05-16 | 2022-12-16 | 中科物栖（北京）科技有限责任公司 | 一种物联网设备控制方法及系统 |
| CN111756847B (zh) * | 2020-06-28 | 2023-05-09 | 北京百度网讯科技有限公司 | 网站支持https协议的方法和装置 |
| CN111814085A (zh) * | 2020-07-10 | 2020-10-23 | 四川长虹电器股份有限公司 | 基于JavaScript hook的新型WEB在线代理方法 |
| CN113079210A (zh) * | 2021-03-29 | 2021-07-06 | 广东电网有限责任公司 | 一种跨区数据自动同步的配置方法、终端设备及存储介质 |
| CN114500487A (zh) * | 2021-11-15 | 2022-05-13 | 广州方阵科技有限公司 | 一种端到端超文本传输协议转换系统 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1487711A (zh) * | 2002-09-03 | 2004-04-07 | �Ҵ���˾ | 网络系统、反向代理、计算机设备、数据处理方法以及程序产品 |
| CN1512707A (zh) * | 2002-12-27 | 2004-07-14 | �Ҵ���˾ | 代理服务器、访问控制方法和访问控制程序 |
| CN101116311A (zh) * | 2005-04-06 | 2008-01-30 | 国际商业机器公司 | 实现用于web服务的授权策略的方法和系统 |
-
2008
- 2008-12-03 CN CN 200810227971 patent/CN101753606B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1487711A (zh) * | 2002-09-03 | 2004-04-07 | �Ҵ���˾ | 网络系统、反向代理、计算机设备、数据处理方法以及程序产品 |
| CN1512707A (zh) * | 2002-12-27 | 2004-07-14 | �Ҵ���˾ | 代理服务器、访问控制方法和访问控制程序 |
| CN101116311A (zh) * | 2005-04-06 | 2008-01-30 | 国际商业机器公司 | 实现用于web服务的授权策略的方法和系统 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106375976A (zh) * | 2015-07-22 | 2017-02-01 | 中国移动通信集团公司 | 一种Web应用计费的方法及装置 |
| CN106375976B (zh) * | 2015-07-22 | 2020-06-30 | 中国移动通信集团公司 | 一种Web应用计费的方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101753606A (zh) | 2010-06-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101753606B (zh) | 一种实现web反向代理的方法 | |
| US9183188B2 (en) | Dynamic toolbar for markup language document | |
| US7877459B2 (en) | Method and system for modifying requests for remote resources | |
| FI105249B (fi) | Menetelmä ja järjestely informaation liittämiseksi verkkoresursseihin | |
| US9986056B2 (en) | In-server redirection of HTTP requests | |
| US8886828B2 (en) | Selective use of anonymous proxies | |
| US7716282B2 (en) | Proxy server apparatus and method for providing service using the same | |
| US7584500B2 (en) | Pre-fetching secure content using proxy architecture | |
| US8797920B2 (en) | Methods and systems for access to real-time full-duplex web communications platforms | |
| US8763136B2 (en) | Privacy enhanced browser | |
| US8589484B2 (en) | Method for optimizing a web content proxy server and devices thereof | |
| CA2824222C (en) | Methods and systems for the dynamic creation of a translated website | |
| US8234406B2 (en) | Method of redirecting client requests to web services | |
| JP4867486B2 (ja) | 制御プログラムおよび通信システム | |
| US20110131478A1 (en) | Method and system for modifying script portions of requests for remote resources | |
| US9225510B1 (en) | Website secure certificate status determination via partner browser plugin | |
| CN101136834B (zh) | 一种基于ssl vpn的链接改写方法和设备 | |
| CN103955501A (zh) | 一种网页双向协同浏览方法 | |
| US7093019B1 (en) | Method and apparatus for providing an automated login process | |
| KR20060112630A (ko) | Ｔｃｐ세션 가로채기를 이용한 광고 송출 시스템 및 방법 | |
| WO2002027552A2 (en) | Enhanced browsing environment | |
| JP4882738B2 (ja) | クライアント装置、通信方法およびプログラム | |
| TWI472205B (zh) | A system for implementing an HTTP request service and a method thereof | |
| WO2002021312A2 (en) | System and method for facilitating coordinated browsing of data objects | |
| KR100624701B1 (ko) | Ｈｔｔｐ 중계기, 이를 구비한 추가정보전달시스템 및추가정보 전달방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C56 | Change in the name or address of the patentee |
Owner name: BEIJING TOPSEC TECHNOLOGY CO., LTD. Free format text: FORMER NAME: BEIJING HEAVEN MELTS LETTER SCIENCE TECHNOLOGIES CO., LTD. |
|
| CP01 | Change in the name or title of a patent holder |
Address after: 100085 Beijing East Road, No. 1, building No. 301, building on the north side of the floor, room 3, room 3 Patentee after: BEIJING TOPSEC TECHNOLOGY CO., LTD. Address before: 100085 Beijing East Road, No. 1, building No. 301, building on the north side of the floor, room 3, room 3 Patentee before: Beijing heaven melts letter Science Technologies Co., Ltd. |
|
| C56 | Change in the name or address of the patentee |
Owner name: BEIJING HEAVEN MELTS LETTER SCIENCE TECHNOLOGIES C Free format text: FORMER NAME: BEIJING TOPSEC TECHNOLOGY CO., LTD. |
|
| CP01 | Change in the name or title of a patent holder |
Address after: 100085 Beijing East Road, No. 1, building No. 301, building on the north side of the floor, room 3, room 3 Patentee after: Beijing heaven melts letter Science Technologies Co., Ltd. Address before: 100085 Beijing East Road, No. 1, building No. 301, building on the north side of the floor, room 3, room 3 Patentee before: BEIJING TOPSEC TECHNOLOGY CO., LTD. |
|
| C56 | Change in the name or address of the patentee | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 100085 Beijing East Road, No. 1, building No. 301, building on the north side of the floor, room 3, room 3 Patentee after: BEIJING TOPSEC TECHNOLOGY CO., LTD. Address before: 100085 Beijing East Road, No. 1, building No. 301, building on the north side of the floor, room 3, room 3 Patentee before: Beijing heaven melts letter Science Technologies Co., Ltd. |
|
| C56 | Change in the name or address of the patentee | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 100085 Beijing East Road, No. 1, building No. 301, building on the north side of the floor, room 3, room 3 Patentee after: Beijing heaven melts letter Science Technologies Co., Ltd. Address before: 100085 Beijing East Road, No. 1, building No. 301, building on the north side of the floor, room 3, room 3 Patentee before: BEIJING TOPSEC TECHNOLOGY CO., LTD. |