基于URL重写技术的电子资源统一授权访问系统的原理和实现

2008-10-30 05:24李洪文
大学图书馆学报 2008年4期
关键词:代理服务器浏览器客户端

李洪文

摘要介绍一种基于URL重写技术的电子资源统一授权访问系统的原理和实现,以及在开发中遇到的问题和解决方法。该系统不仅可以作为电子资源的统一访问门户,还可以应用于校外读者访问图书馆的电子资源。

关键词电子资源URL重写代理服务器单点登录

1、国内电子资源统一授权访问系统发展现状

随着web技术的日臻成熟,图书馆内的各种Web资源数量越来越多,包括图书馆自建的资源网站、购置的国内外电子资源、业务管理网站、以及图书馆自动化系统的OPAC网站等等。随着资源的增多,带来几个主要问题:如何采用统一的界面对使用情况进行各种统计;如何实现这些资源的统一授权访问;如何实现读者在校外访问这些资源。

面对这些问题,高校图书馆都作了相应尝试,目前在国内实现大概有三种方式:

1.1代理服务器方式

比较常见的方式。该方式在授权管理上,利用代理服务器提供的用户管理功能,在客户端浏览器上设置好代理,然后可以畅通地访问图书馆提供的各种网站。利用代理服务器的简单日志作使用情况的简单统计分析。只要把代理服务器的端口和IP在防火墙上开通,校外读者也可以访问。

1.2虚拟专用网络(VPN)方式

通过购买VPN硬件或者使用价廉的软件VPN,在网络传输层实现授权访问,统计数据是基于IP地址以及端口的流量报告,通过分发一些校外的VPN帐号实现校外的资源访问。因为VPN是基于传输层,只关心IP数据包正确地实现端到端的传输,因此不分析应用层的HTTP协议,所以无法对URL进行统计分析。权限控制方面只能做到对IP的黑白名单控制,对于同一台资源服务器上的多个网站应用,就无能为力了。

1.3基于重写URL技术的方式

以国外的EZProxy软件为主。在国外,URL重写技术已经得到较为广泛的应用。基于URL重写技术的系统,更容易被读者使用,无需客户端。主要有以下5个方面的优点。

(1)实现所有管辖网站的透明访问。

(2)可以实现网站间的单点登录。因为URL重写服务器本身使用的就是HTTP协议,因此在多个网站间通过架设一个认证服务器,通过跨域名Cook-ie技术,容易实现单点登录。用户在门户网站登录后,再进入各个资源。

(3)实现用户权限统一管理。在使用该系统前,学校校园网当有IP地址调整的时候,需要对每种电子资源进行授权IP地址的修改。使用该系统后,统一进行IP用户管理,只需要添加一次即可。

(4)既可以在URL级别非常容易地实现各种统计,比如访问次数;也可在网络流量上进行各种统计。可以做成各种折线图、统计报表,来反映各类资源在某个时间段内的使用情况。

(5)可以实现多台主机负载均衡,实现无瓶颈访问。山东大学目前共有4台主机做访问的动态均衡。在多台主机间通过身份认证服务实现单点登录。

经过对三种解决方案的利弊权衡,山东大学图书馆采用URL重写技术,与公司合作,对原有的校外访问系统进行改造,协同开发了一套适合高校图书馆的资源统一授权访问系统。

2、URL重写的方式

2.1基于URL地址的重写

URL地址重写就是把网站的URL地址以及网页中的所有真实URL地址(包括图片、FLASH、链接等),转换成一个以重写代理服务器地址开头,其后紧跟着该URL地址的一个长URL地址。

比如图书馆OPAC的地址是http://202.194.11.6/,URL重写代理服务器的地址是http://url-proxy1.my.com/,那么经过URL重写后的OPAC的地址可以是:http://urlproxy1.my.com/202.194.11.6/。然后把202.194.11.6服务器的80端口通过防火墙关闭,发布公开的地址http://urlproxy1.my.com/202.194.11.6/作为所有读者访问的地址。

鉴于重写后的URL地址太长,上述例子的改进方案可以为202.194.11.6起个别名,然后重定向到这个URL地址。比如改为:http://urlproxy.1my.com/opac/,当读者从浏览器访问这个地址的时候,实际上是访问的OPAC 202.194.11.6网站的内容。

网站HTML页面里的所有的URL地址,都必须得到重写,否则当用户在这个页面点击没有被重写的URL链接,浏览器就会转向链接所指向的原始的网站去了,不会通过我们的重写服务器。系统会对页面里大多数URL地址进行自动重写。但因为网页内Javascript脚本复杂多样,计算机不能全部识别。因此对于部分网页需要通过配置过滤器,来告知重写服务器对这些脚本中的URL如何重写。这种方式的优点是服务器只需要用一个端口即可实现所有电子资源的访问。

因基于URL地址重写的灵活性和硬件配置要求低的优点,我们采取了这种方式。

2.2基于端口的重写

就是把电子资源URL的主机端口,影射到重写服务器的某个端口。例如:把www.cnki.net端口影射到urlproxy.my.com:8000上,把www.sciencedirect.com影射到urlproxy.my.com:80001上。基于端口重写的优点是大大降低重写配置难度,但是缺点是明显的,每增加一个资源,需要单位防火墙开放一个端口。

3、开发平台的选择

采用J2EE开发平台,Tomcat6.0作为Servlet容器,JDK采用1.6版本,数据库采用MySQL 5。开发集成环境采用Eclipse 3.0,后台系统管理采用Struts1.3,并基于Ajax技术的ExtJS 2.0作为管理框架。

4、系统的基本实现

4.1重写器的实现

采用java.util.regex包中提供的标准正则表达式类库,通过写URL地址的匹配正则表达式,来对网页内容进行搜索和替换。共有3种类型的重写器:

(1)基本的HTML标签重写器。如A、IMG、FORM等标签中的HREF、SRC、ACTION属性等等,这些属性的值一般都是URL地址,需要将这些地址进行重写处理。

(2)脚本重写器。对之间的内容进行表达式分析,抽取地址相关的内容进行地址重写。

(3)自定义重写器。上述两个重写器都是系统自动完成的。对于少数网站可能还有些地址没有被检测和重写到,那么用户可以自己定义重写器。

此外,需要对HTTP回应数据进行检测,只对文本的回应进行重写。图片等二进制数据不作重写处理。有些gzip或者deflate格式的二进制数据,需要解压缩后再进行重写,可以采用java.util.zip.GZIP-

InputStream类和java.util.zip.InflaterInputStream类解压缩。

4.2后台Web管理的实现

采用基于Ajax技术的胖客户端方式,ExtJs 2.0作为UI框架,实现用户管理、授权管理、电子资源管理、流量动态监控、流量分析、资源使用率和点击率等分析。

4.3与图书馆统一认证系统的挂接

采用Saml标准,与图书馆认证中心提供的Web-Service进行交互,实现统一身份认证和单点登陆。

5、开发中遇到的问题及解决方法

5.1浏览器Cookie数量限制的问题

如果同时访问了2~3个资源,就有可能出现某个资源经常提示未登录。这是Web浏览器关于Cookie个数的限制所导致的。根据rfe2965(Cookie规范)里定义的,对于一个浏览器同时能够存储的Cookie数量:

(1)总共300个Cookie。

(2)每个Cookie 4K的存储容量。

(3)每一个域名或者服务器20个Cookie。

把所有的电子资源都放在URL重写服务器下访问,会导致这些电子资源的Cookie都存储在一个域名里。因此,如果代理的电子资源数多了,浏览器只会保留最近20个Cookie,而其余的将全部丢弃。登录的会话ID(SessionlD)是首先保存在浏览器Cookie中的,因此当Cookie个数超过20个的时候,也是首先被丢弃的,所以电子资源会频频出现登录提示。

有两种解决方案,我们采用的是前者。

(1)将Cookie存储在客户端。

Cookie经过特殊编码,将多个Cookie合并为一个Cookie,存储在客户端的浏览器中。用户每发送一次请求,URL重写服务器从代理后的目标网站传回的Response中提取该资源网站所有的Cookie,将这些cookie压缩和编码,生成一个新的Cookie,然后通过Set-Cookie发给Web浏览器进行存储,这是Cookie的压缩过程。重写器访问目标网站的时候,会根据Web浏览器提供的压缩后的Cookie,将其解压缩还原成多个Cookie,再发送到目标资源网站,这是Cookie的解压缩过程。通过这种方案,可以允许用户同时访问19个资源网站(因为URL重写服务器也需要占用一个Cookie来存放SessionID),这个数量基本够用了。

(2)将Cookie存放在服务器端的Session中。

通过在URL重写服务器端的Session中维护一个Cookie的HashMap,来管理这些目标网站的Cook-ie信息。该HashMap提供与新接收到的Cookie合并的功能,同时能够删除过期的Cookie,更新同名的Cookie。

5.2电子资源中FTP全文下载的问题

如果电子资源中的全文是以FTP方式存放,就会遇到这个问题。解决方法:做一个FTP到HTTP的网关,将FTP请求和回应做封装,在HTTP的头中增加Content-Disposition头,来指定文件名,把FTP文件数据放在HTTP回应中。

5.3对于非HTTP的通讯协议资源的解决方法

极少数资源使用了单独的客户端以及自定义的非HTTP的通讯协议,不能通过URL重写技术实现。我们通过开发客户端插件,并在重写服务程序里增加一个SOCKS代理模块来实现。客户端插件采用APIHOOK技术,接管这些非HTTP协议的客户端的所有网络SOCKET调用,将目标地址转向到重写服务器的SOCKS服务器。但是要求读者在访问该资源的时候,必须安装客户端插件。

6、山东大学图书馆的系统部署

山东大学目前已经将30多种资源通过URL重写服务器,向读者提供服务。IBM X346服务器作为认证服务器和主URL重写代理服务器。均衡的重写代理服务器配置安装在部分资源服务器上,做为流量的分流。图书馆内镜像的Web资源,将其原始地址通过防火墙隐藏,向读者发布的是重写后的URL地址。当用户访问的资源未经过认证,会弹出认证页面进行认证;如果已经认证过,那么访问该资源就和访问原始的资源效果完全一样。

用户分为登录用户和IP机构用户两种。登录用户账号提供给读者在校外访问。IP机构用户是指读者在校园网内访问该系统,只要读者的IP地址在校园网IP范围内,则系统自动影射为与该IP对应的某个机构用户账号上,比如某教研室的账号。

7、结束语

该系统经过近两年的稳定运行,得到了广大读者的好评,已经成为教师访问图书馆资源的主要方式之一。并且和CALLS统一认证做了接口,提供本地和CALIS统一认证两种登录方式。

2008年年初,山东大学图书馆还申请了一条网通的100M数据专线来为校外提供更好的服务。系统支持教育网和网通两条网络接口,并实现统一认证。

为了更好地服务读者,该系统将会继续完善和发展,将其应用扩展到非HTTP应用上,增强客户端插件的功能,使读者可以通过该系统访问更多的资源。

猜你喜欢
代理服务器浏览器客户端
拒绝改动锁定电脑的代理服务器设置
反浏览器指纹追踪
地铁信号系统中代理服务器的设计与实现
县级台在突发事件报道中如何应用手机客户端
孵化垂直频道:新闻客户端新策略
基于Vanconnect的智能家居瘦客户端的设计与实现
IP地址隐藏器
环球浏览器
客户端空间数据缓存策略
一种容侵系统的设计