您现在的位置: 365建站网 > 365文章 > Ajax访问Xml Web Service的安全问题以及解决方案

Ajax访问Xml Web Service的安全问题以及解决方案

文章来源:365jz.com     点击数:484    更新时间:2009-09-14 10:46   参与评论

在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中添加如下方法:

[WebMethod] 
public bool UserAdd(string userName,string
 pwd) 

return true

}
 

注意服务类上部要添加Attribute

[System.Web.Script.Services.ScriptService]

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

<asp:ScriptManager ID="ScriptManager1" runat="server"> 

<Services>
 

<asp:ServiceReference Path="UserService.asmx" />
 

</Services>
 
</asp:ScriptManager>
 

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

<h2>Ajax调用Xml Web Service示例1</h2> 

<div style="border: 1px solid Black; width: 50%; padding: 10px;">
 

<table class="style1">
 

<tr>
 

<td>
 

用户名: 

</td>
 

<td>
 

<input id="txtName" type="text" />
 

</td>
 

</tr>
 

<tr>
 

<td>
 

密码: 

</td>
 

<td>
 

<input id="txtPwd" type="password" />
 

</td>
 

</tr>
 

<tr>
 

<td>
 

&nbsp;
 

</td>
 

<td>
 

<input id="Button2" type="button" value="提交" onclick="userAdd()" />
 

</td>
 

</tr>
 

</table>
 

</div>
 

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

function userAdd() 



var name = $get("txtName"
).value; 

var pwd = $get("txtPwd"
).value; 

AjaxWs.UserService.UserAdd(name,pwd,userAddCallBack); 

}
 

function
 userAddCallBack(res) 



alert(res); 

}
 

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一致,只是添加上访问限制

[WebMethod(EnableSession=true)] 

public bool UserAddSecurity(string userName, string pwd) 



if (Session["UserID"== null




return false


}
 

return true


}
 

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

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

protected void Button3_Click(object sender, EventArgs e) 



Session[
"UserID"= "jillzhang"


}
 

点击登陆按钮后,再次点击提交,便可以返回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终结点去掉,这样就可以解决上面的问题。具体实例下文讨论,有点困了,睡! 

 附上示例项目:

/Files/jillzhang/AjaxWs.rar

 

如对本文有疑问,请提交到交流论坛,广大热心网友会为你解答!! 点击进入论坛

发表评论 (484人查看0条评论)
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
昵称:
最新评论
------分隔线----------------------------

快速入口

· 365软件
· 杰创官网
· 建站工具
· 网站大全

其它栏目

· 建站教程
· 365学习

业务咨询

· 技术支持
· 服务时间:9:00-18:00
365建站网二维码

Powered by 365建站网 RSS地图 HTML地图

copyright © 2013-2024 版权所有 鄂ICP备17013400号