问题分析排查

由于他用的是笔记本，在家里和在公司访问时的系统环境是一样的，这样也就排除了系统环境的原因。那只能怀疑是网络环境的问题了。后来在现场使用HTTP Watch调试发现，当Silverlight在下载其中几个缓存程序集的zip包（我们的Silverlight应用程序启用了Assembly Caching）时，HTTP请求被302永久重定向到一个奇怪的IP上。

这样，由于zip包和Xap包地址的主机域不同，构成跨域，Silverlight会要求zip包所在的网站提供clientaccesspolicy.xml或者crossdomain.xml文件。而那个奇怪的IP所在网站下根本就没有这两个文件，所以请求失败。进而导致整个程序挂掉。

Assembly Caching程序集缓存

Assembly Caching（又称Application Library Caching）是Silverlight 3的新特性。以前Silverlight都是将所有用到的dll放到一个xap包之中，这样整个xap包会很大，下载相对比较慢。启用Assembly Caching之后，Silverlight工程用到的dll就可以在编译的时候自动打包到各自的zip包中，然后Silverlight在加载Xap包之后会自动下载这些zip包并解压出里头的dll，然后加载到应用程序域中。这样一来可以大大提高程序集下载的并行度，同时也可以使到不同Silverlight程序之间可以利用浏览器缓存而无需重复下载。

Silverlight在加载Xap包之后会去读取xap包中的appmanifest.xaml文件，然后下载该文件中指定的程序集文件。如果程序集文件Url和当前Xap包Url构造跨域（参考Silverlight SDK文档），则Silverlight会向该程序集所在网站的根目录请求跨域策略文件。

为什么会被重定向

这个问题困扰了我们很久。当时我们的第一反应是怀疑网关设置了什么规则。当用户访问特定Url的时候，触发了这个规则，导致HTTP请求被挟持。但是和客户公司网管沟通之后，对方明确表示并没有设置过类似的规则。

直到最近，客户和电信通（率属铁通）的人沟通之后，那边的技术人员说这是由于铁通的缓存加速服务器造成。据说是铁通为了让用户下载更快，就将某些HTTP请求进行重定向。后来电信通的技术人员告诉客户他们已经没问题了，但是他们并没有告知详细的问题所在，到底是由于我们的HTTP请求碰巧符合特定规则，还是怎么回事。也不知道他们是怎么解决的，是只将客户公司的IP列入禁止缓存列表，还是将我们Silverlight应用程序使用的域名加入禁止缓存列表，我们都无从知道。对于我们来说，这并没有真正解决问题。如果将来其他客户也通过铁通访问我们的产品，那么可能还是会出现类似的问题。由于我家里也是铁通的网络，所以我决定自己研究一下到底是怎么回事。

由于铁通那边没有任何可用的技术信息，Google也没有找到有价值的信息，唯一猜测的就是HTTP请求可能符合特定规则然后就被无辜重定向了。因此我只能采用最原始的人肉测试了。尝试不断的调整出问题的Url然后看是否被重定向了来发现规律。修改zip包所在目录，修改zip包文件名，修改zip包后缀，修改IIS的MIME类型，测试不同域名，等等。在历经100多次尝试之后，终于发现了当文件大小超过40K左右，并且后缀名是zip或者rar等常见的下载文件后缀，就会被铁通重定向。而且有时候第一、二次不会被重定向，刷新多几次的时候就才会被重定向。后面一点让我走了不少弯路，多少次我以为找到规律了，最后验证结论的时候还是错了。

o(︶︿︶)o

怎么解决

知道具体问题所在之后，我们几个技术人员就开始讨论如何解决这个问题。由于Silverlight对于缓存程序集打包之后的文件后缀没有要求，不管什么后缀，都会以zip文件流的格式去解析。因此可以修改打包文件的后缀来“逃过”铁通的魔掌。

修改文件后缀也有两种方法。

一种是在部署的时候，通过自动化脚本，修改所有zip文件后缀，然后修改xap包中appmanifest.xaml里头程序集的Url。这种方式的好处是一劳永逸，通用性强，以后部署的时候只需要执行一次脚本即可，其他应用程序可以共用。缺点是脚本编写比较复杂，并且部署的时候需要多加一步。

另外一种方法是将用到的Silverlight系统程序集放到工程底下，然后修改同名的xml配置文件，使其打包的文件使用其他后缀名。好处是这样编译完之后就可以直接部署了，无需执行什么操作，也不需要写脚本。坏处就是首先需要修改所有现有的工程，而且以后如果要开发新的Silverlight应用，也要记得这么做。

不管怎么样，这两种方法都不简单。后来我就想，既然客户可以和电信通联系，为什么我不可以直接和铁通联系呢。我就上网搜了一下北京铁通客户中心，找到申诉通道，填写完整的申述理由。然后第二天又打他们的客服电话去骚扰他们。结果过了两天，申述结果就下来了，“问题已解决”。对方客服还本着能自己动手决不麻烦别人的精神，帮我填写了用户满意度一栏：“非常满意”。

更深层的东西

其实最终解决问题的办法非常简单，就是投诉。我不满意你的服务，我就有权利投诉你。可是为什么一开始没有意识到这种解决办法呢？

我觉得这是和我们接触的社会环境有很大关系。我们潜意识里头已经习惯了各种中国式的流氓。运营商喜欢往你访问的网站中插播广告，访问我自己的博客偶尔还有弹窗广告；上Google搜索技术资料，一不小心点了blogspot的链接就导致Google被重置了，然后就10分钟不可用。没有明文规定告诉你什么是被禁止的，我们只能人肉测试。我们除了接受、适应并绕过这种事实之外还能做什么？也许我们还可以发出几声“中国式的抗议”吧。

言多必封，不多说了。

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Asp.Net页面的编码问题
• Blend小贴士——改变鼠标滚轮的默认行为
• IIS中使用子目录文件作为默认文档（Default Document）替代重定向
• Silverlight 2 RTM 多国语言支持（应用程序本地化）
• Silverlight 2动态加载Xap包中的程序集
• Silverlight 4+RIA Services–搜索引擎优化(SEO)
• Silverlight SEO（搜索引擎优化）白皮书
• Silverlight2 动态加载程序集—OnDemand模式(Dynamic Load Assembly)
• Silverlight中无法设置卫星程序集为中立资源程序集

问题

最近将一个Silverlight应用从一个域挪到另外一个域下之后，出了一些莫名其妙的问题。在加载完Silverlight之后，整个Silverlight UI一闪就消失了。左下角没有异常信息，异常报错的窗口——系统会捕获到所有异常，将其使用Alert方法展示给用户——也没有弹出来。

后来使用HTTP Watch观察了一下，发现在调用web service的时候服务端返回了错误（服务端会将异常封装成一个自定义的数据结构返回给客户端）。奇怪的是，既然返回了错误，按理应该会弹出窗口显示错误信息才是，但是却什么信息也没弹出来，整个UI界面一闪就消失了。

查了很久之后终于找到相关的资料，原来Silverlight和宿主（承载Silverlight应用的网页）Dom元素和脚本的交互在跨域下也有一些限制。

Silverlight HTML桥的安全设置

在Silverlight2中，有三个参数控制着Silverlight和HTML的交互行为。

• enableHtmlAccess —— Silverlight插件属性，禁止恶意的基于 Silverlight 的跨域应用程序访问主页面的 JavaScript 和 DOM 代码。
• ExternalCallersFromCrossDomain —— 部署清单属性，禁止恶意的跨域宿主访问由基于 Silverlight 的应用程序公开的可编写脚本的属性、方法或事件。
• AllowHtmlPopupwindow —— Silverlight插件属性，控制基于 Silverlight 的跨域应用程序打开的弹出窗口。在此属性设置为 false 时（在从包含页或承载 iframe 以外的其他域加载 Silverlight 控件时的默认值），开发人员无法调用 [HtmlPage.PopupWindow]。

enableHtmlAccess

这个属性是在Silverlight插件中配置的。它使到Xap包中的托管代码可以访问宿主页面中的DOM元素以及Javascript代码。此插件一旦初始化之后就是只读的。在同域情况下，此属性默认值为true，而在跨域情况下（宿主和Xap包不在同个域下）默认值为false。这也就是为什么我们一般情况下不需要设置此参数的缘故。

<div id="silverlightControlHost">
    <object data="data:application/x-silverlight," type="application/x-silverlight-2" width="300" height="100">
        <param name="source" value="http://www.domain1.com/silverlightapp.xap"/>
        <param name="enableHtmlAccess" value="true" />
    </object>
</div>

将此属性设置为true之后才可以访问以下对象：

• HtmlPage.Document
• HtmlPage.Window
• HtmlPage.Plugin
• HtmlPage.BrowserInformation

这也就解释了文章开头提到的问题。

因为在出问题的Silverlight应用中，会捕获所有的异常，并将异常描述信息通过HtmlWindow.Alert方法展示给用户。而Alert的实现应该也是通过调用Javascript的alert函数来完成的，因此在跨域情况下，如果直接调用跨域宿主的Javascript代码是会抛出异常的。不过对于此异常Silverlight的处理行为还是很糟糕的。

如果出于某种目的需要禁用此属性，防止Silverlight意外篡改宿主Dom元素，或者限制Silverlight可访问的Dom元素，那么可以采用以下步骤实现：

1. 通过ScriptableTypeAttribute或者ScriptableMemberAttribute属性声明一个可以被Javascript访问的Silverlight对象

2. 通过RegisterScriptableObject显式注册此对象以供Javascript访问

3. Javascript调用此对象接口，将所需要的Dom元素传给Silverlight托管代码

需要注意的是，这种方式是由Javascript发起的操作，需要配置ExternalCallersFromCrossDomain属性为true。

ExternalCallersFromCrossDomain

ExternalCallersFromCrossDomain属性是在部署清单appmanifest.xaml中配置的。它是用来限制跨域情况下脚本对Silverlight托管代码的访问的，在同域情况下此属性无效。配置示例如下：

<Deployment xmlns="http://schemas.microsoft.com/client/2007"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    EntryPointAssembly="MyAppAssembly"
    EntryPointType="MyNamespace.MyApplication"
    ExternalCallersFromCrossDomain="ScriptableOnly"
>
<Deployment.Parts>
    <AssemblyPart Source="MyAppAssembly.dll” />
    <AssemblyPart Source="MyUserControl.dll" />
  </Deployment.Parts>
</Deployment>

此属性有两个取值，ScriptableOnly和NoAccess（beta2的FullAccess取值在正式版的时候已经废弃了）。当设置为ScriptableOnly时，Javascript可以访问Silverlight托管代码显式注册的脚本入口，而不能查询或设置其他对象的属性。另外，它也不接受事件通知。如果设置为NoAccess，那么Javascript无法访问托管代码里的任何对象接口。

关于这两个属性的详细信息，参见SilverlightHTML 桥中的安全设置。

——Kevin Yang

你可能对下面的文章感兴趣

• Button标签鼠标点击事件的触发源问题
• Pre标签内文字自动换行（兼容多数主流浏览器）
• Silverlight 2动态加载Xap包中的程序集
• Silverlight2 动态加载程序集—OnDemand模式(Dynamic Load Assembly)
• Silverlight启用Assembly Caching之后铁通用户无法访问
• WordPress评论中保留Html代码
• 图片等资源的引用路径问题
• 莫名其妙的Silverlight资源文件引用问题
• 谈谈Silverlight的一个跨域安全考虑

在文档中有这么一段话：

There are important security considerations before you allow Silverlight clients to access Web services in a cross-domain situation. Whenever you put a cross-domain policy file in place you should configure your Web server hosting the Web services to disable browser caching. This enables you to easily update the file or restrict access to your Web services if necessary. Once the cross-domain policy file is checked, it remains in effect for the browser session so the impact of non-caching to the end-user is minimal.

In addition, all Silverlight requests are sent with cookies and authentication. This means that if you have Web services that allow users to access private information, you should host these in a different domain than the Web services exposed to third-party callers. For example, you have a Web store hosted at http://www.tailspintoys.com. Your site allows customers to store billing information that includes credit card numbers. You should not expose a Web service that returns product inventory to third-party Silverlight clients at the same domain. Because cookies and authentication are sent with each message, if you host these Web services on the same domain, you have effectively given the third-party callers access to your customer's private billing information. In this example, your publicly exposed Web services could safely be hosted at http://services.tailspintoys.com, because this is a different domain. You must carefully consider who you have exposed Web services to, and what other Web services are located at that domain. Also, you should always keep your cross-domain policy file as restrictive as possible. For more information about exposing secure Web services, see Security Considerations for Service Access and Making a Service Available Across Domain Boundaries.

我对第二段做了个简单的翻译：

所有的sl请求都会将Cookie和身份验证信息连同发送。这就意味着如果你有一个Web服务，允许用户访问隐私信息，那么你应该将这个web服务放置在其他的域下，和暴露给第三方调用者的web服务的域名区分开。例如，如果你有一个网店放置在http://www.tailspintoys.com，你的网店允许客户存储交易的信息，其中包含了信用卡号码。那么你不应该将一个返回产品清单的web服务放在同个主机域下，然后暴露给第三方的SL客户端。因为Cookie和身份验证信息会和请求连同发送，如果你将这些web服务放置在同个域下的话，你就给了第三方的调用者一个很方便的途径来访问你的客户的私人交易信息。在这个例子中，你暴露给第三方的web服务应该放置在http://services.tailspintoys.com。因为这是一个不同的主机域。你必须非常小心的选择哪些服务可以公开，哪些服务应该部署在那个域下。

我们知道Cookie中有一个主机名的属性，对于只有对于同个主机域的请求，浏览器才会把Cookie连带发送。SL也不例外。

假设这么一种场景：淘宝开放了一个Web服务，这个服务干什么我们并不关心。但是我们知道，如果你想要你的Web服务被其他第三方的客户端调用，你必须在网站下放置一个特定的xml文件，我们称为"安全策略配置"文件，Flash对应的是crossdomain.xml文件，Silverlight除了支持Flash的这个策略文件之外自己也有一套策略配置，放在clientaccesspolicy.xml文件中。与Flash不同的是，SL只会从网站的根目录下去寻找这个策略文件，也就是说即使你的web服务是放在/serivce/目录下的，那么SL客户端也会查找"主机名/clientaccesspolicy.xml"这个文件是否存在（我不清楚为什么要这样设计）。因此淘宝为了让他的Web服务被Silverlight支持，就必须在网站根目录下放置一个策略文件。

假设一个顾客在淘宝www.taobao.com 上面购买了一些东西，登录的会话验证信息可能会存放在Cookie中，然后这个顾客又访问了一个恶意网站（www.eyi.com 当然域名没那么弱了^^），这个恶意网站会向淘宝发送一些登录的HTTP请求。因为这个时候是属于跨域请求，所以Silverlight Runtime会去查找网站根目录下有没有这个策略文件，发现有（并且通过了文件里面定义的访问权限的验证），那么这个请求就会被允许，同时会把你在www.taobao.com 上面的Cookie也连带发送到淘宝系统那里，那么这个时候，这个恶意网站是不是就在你不知情的情况下登录到了淘宝后台，然后这个时候他就可以执行一些你不期望的操作了。

当然这个例子能不能work还有待商榷，只是通过这个例子想告诉大家的是，对于策略安全文件一定要非常小心的配置好访问权限，暴露给第三方的Web服务（涉及到跨域策略安全的），最好放在一个隔离的域下，这样可以降低安全风险。

不知道我这样理解有没有问题，如果不正确的话请纠正我~

下面这张是Silverlight的跨域场景示意图

还要说明的一点是，Silverlight Runtime在检测安全策略文件时，是先检测clientaccesspolicy.xml 再检测crossdomain.xml文件（当然拉，自己的东西肯定先检测了）。一旦请求完成，策略文件在整个应用程序会话周期内一直有效（这个感觉和浏览器为了防止DNS Rebinding攻击的做法是类似的），也就是说不用每次都请求这个文件了。如果第一次请求该文件失败，那么接下来的请求同样的也会失败。

策略文件只能放置在根目录下，无论你当前请求的资源是位于网站的哪个目录下。

策略文件本身不允许服务器将其重定向，响应的状态码只能是200或者404，但是请求的资源本身是可以被重定向的，只要源URL和目标URL都在跨域策略文件中声明了。

——Kevin Yang

你可能对下面的文章感兴趣

• Blend小贴士——改变鼠标滚轮的默认行为
• Silverlight 2 RTM 多国语言支持（应用程序本地化）
• Silverlight 2动态加载Xap包中的程序集
• Silverlight 4+RIA Services–搜索引擎优化(SEO)
• Silverlight SEO（搜索引擎优化）白皮书
• Silverlight2 动态加载程序集—OnDemand模式(Dynamic Load Assembly)
• Silverlight中无法设置卫星程序集为中立资源程序集
• Silverlight启用Assembly Caching之后铁通用户无法访问
• Silverlight的依赖属性与附加属性
• 图片等资源的引用路径问题