Ajax访问XmlWebService的安全问题以及解决方案

在asp.net ajax中updatepanel比较常用,原本需要刷新的操作套在updatepanel中就成了ajax操作了,挺帅!但ajax也是支持与Xml Web Service交互的,这种方法更像是传统的ajaxpro和其他ajax框架,如jquery,magicajax,extjs的风格,但MS总是独树一帜,谁让他的产品设计能力那么高呢!我辈恐怕望尘莫及亚.闲话少叙，下面简单讲述下asp.net ajax如何调用xml web service,熟悉的朋友就略过吧

1. 创建一个支持Asp.Net Ajax的网站或者网络应用程序，我使用的是vs2008，在vs2008中，如果建立的网站支持.net framework 3.5就有ajax的缺省支持，这陈芝麻，烂谷子的事情，也不多说。

2. 建立好项目之后，在网站根目录中添加一个Web服务UserService.asmx,在UserService.asmx中添加如下方法：

注意服务类上部要添加Attribute

[System.Web.Script.Services.ScriptService]

3. 然后把default.aspx中的ScriptManager修改成如下代码的德性：

下面我们就在页面中创建用Ajax消费这个UserService的代码：主要包括如下：

在<head></head>添加如下脚本

4. 好，现在一个简单的ajax调用web service的示例代码已经搞定，罗索了不少，其实简单的不能再简单，运行页面，点击提交按钮，效果如下：

表示成功。一般人这一步都会成功的。二般的除外亚，：）

一些正常，那是不是到这里就万事大吉，ajax万岁！web service真好！下面是略加思考之后的问题

问题一：

上面的Xml Web Service没有任何保护，如果UserAdd是一个数据库插入操作，那这个操作往往系统只被经过授权的人才能调用成功。以前看有朋友讨论ajax如何调用带有SoapHeader的xml web service，细细想想，其实没什么必要！js是客户端的东西，是放出去收不回来的玩意，天知道用户是哪路货色，如果将身份信息试图通过js传递给SoapHeader，那密码被截获的可能性就比较大。正确的做法其实是Session .我们知道Web Service方法中添加一个[WebMethod(EnableSession=true)]就能使用Session了，Session这家伙专门用于保持会话，有这样一个认识之后，新增一个网络服务方法，这个方法实现功能和起初的UserAdd一致，只是添加上访问限制

在页面中将AjaxWs.UserService.UserAdd(name,pwd,userAddCallBack);更改为AjaxWs.UserService.UserAddSecurity(name,pwd,userAddCallBack);点击提交按钮，会发现弹出结果为false!

在页面中添加一个按钮，点击这个按钮模拟登陆，点击代码为：

点击登陆按钮后，再次点击提交，便可以返回true。这样便限制了用户对xml web service的访问。达到了解决问题一的目的。

问题二:

这个问题涉及到xml web service架构的缺陷，这个缺陷在WCF中已经有所更正和弥补。我们知道web service是一种强度公开和共享的技术，之所以称之为服务，必然是提供给其他应用程序所使用。但事实上，有很多服务是服务于局部或者特殊个体的，而不是理想中的大众。而在原来老的xml web service中，wsdl的发布与网络服务的发布是绑在一起的，我将.asmx部署到iis中，那在这个.asmx后加上?wsdl就能访问服务的wsdl。wsdl是对服务的描述，知道它，便能开发客户代理，从而消费服务，但这样有问题：我的服务只想让局部或者特殊的几个人知道，其他人根本不想让其访问到。这就麻烦了。我发布.asmx,wsdl就发布。而wsdl的发现依靠的是UDDI，通过下面的一段描述：

UDDI 如何被使用

假如行业发布了一个用于航班比率检测和预订的 UDDI 标准，航空公司就可以把它们的服务注册到一个 UDDI 目录中。然后旅行社就能够搜索这个 UDDI 目录以找到航空公司预订界面。当此界面被找到后，旅行社就能够立即与此服务进行通信，这样由于它使用了一套定义良好的预订界面。

如果遍历UDDI目录，不难发现WSDL，发现WSDL后便可以开发客户端与服务交互。这可不是好事情，在问题一中，用授权的方法可以解决一种问题，但假如我的服务是这样的，它返回服务器当前时间，这个方法对于我网站的用户而言是公开的，如果生硬的加上Session，有些麻烦。但这个服务我只希望我自己的ajax能访问，不希望别人发现并调用，但原来的xml web service架构的确不能满足这个需求。如果被一个攻击者发现，他可能会根据公开的wsdl开发客户端，然后不停的ddos攻击，灾难！

上面这个问题对于原来的web service，我还是没有好的解决方案，当然不代表没有解决方案。有朋友知道，劳烦指教。

但对于WCF架构，就充分考虑到上面这个问题了。看看下面老的Xml Web Service架构与WCF架构之间的对比:

1) 老架构

2) 新架构

区别很明显，老架构MEX与业务耦合度非常高，俨然一体，而新的架构却将两者份将开来，分而不僵，反而会增加灵活性。如果是WCF开发的服务，在发布网站的时候，完全可以通过配置，将MEX终结点去掉，这样就可以解决上面的问题。具体实例下文讨论，有点困了，睡！

附上示例项目：