clientaccesspolicy.xml突然停止工作（WCF/Silverlight）

Question

非常沮丧与所有这一切，希望有人可以协助。

我有一个Silverlight应用程序和WCF一起工作，一年没有问题。为了让他们工作，我最初有些痛苦，但终于在帮助下完成了它。所有的痛苦都来自配置/安全性，401的，跨域的地狱等。

我有一切设置的方式是，我有一个WCF服务驻留在它自己的应用程序/目录，并运行在它自己的应用程序池。

在同一个Web服务器（IIS7）上，我有另一个指向上述服务的Silverlight应用程序的应用程序/目录。

服务器名称（本练习）是WEBSERVER1。我们为它创建了一个名为WEB1的CNAME。在过去，如果用户去http://WEB1/MyApp/或http://WEBSERVER1/MyApp/它会起作用。突然昨天它开始表现不好。普通用户开始获得Windows挑战/响应提示（即使他们输入信息他们将得到401错误）。

我的WCF服务在启用匿名访问的站点中运行（并且这一直工作）。 我的Silverlight应用程序在集成了Windows的站点中运行（并且这一直工作），因为我们在连接时捕获了Windows用户名。

为了记录，我昨天创建了一个新的应用程序池，其中运行了ASP.NET应用程序。这似乎工作正常，但有一个机会创建这个新的应用程序池和应用程序/目录已导致改变。

我有一个clientaccesspolicy.xml在我的wwwroot文件夹，以及上述两个应用程序（以防万一）的每个文件夹。我曾试图通过Negotiate作为提供者来推广NTLM（因为这对另一个服务器上的另一个问题起作用）。

在尝试了一些更改后，我甚至无法让我每次调用它时表现得都一样。有时它会提示我输入凭据。其他时候，它会工作，但后来说它无法与“未找到”WCF服务连接。其他时候，它实际上可以正常工作，但前提是我使用的是实际的服务器名称而不是CNAME。在使用CNAME时，即使我在每个目录根目录中都有跨域xml文件，我仍会得到跨域错误。

这是一场噩梦，并且通过比较使得高级算法分析看起来有趣且简单。微软是否意识到他们如何组合这些（IIS7/WCF/Silverlight/providers/permissions /神秘或缺失的错误消息）才能起作用？

Answer 1

我发现了一个似乎正在工作的解决方案。

在这种情况下，我必须将默认网站（托管clientaccesspolicy.xml文件）的身份验证模式从匿名访问更改为Windows集成。我不明白为什么这个工作了一年左右，然后停下来，但似乎已经解决了它。

昨天我部署了一个新的应用程序，它是一个标准的ASP.NET Web应用程序，我把它放在它自己的应用程序目录和它自己的应用程序池中，以确保它不会导致这类问题。我甚至不确定它是否确实如此。

我解决这个问题的方法是试图从我的电脑导航到实际的http://servername/clientaccesspolicy.xml文件，那给了我一个401错误。我从匿名切换到集成在该默认网站上的窗口（除了该XML文件外没有任何内容）并解决了权限问题。然后我不得不允许实际的AD组读取该文件夹（如果他们没有得到user/pw提示符并且无法通过）。