Silverlight+ASP.NET MVC+ Forms Authentication = no authentication in the WCF

I have a standard ASP.NET MVC site with forms authentication. Users log in via a web page. Then they can reach a silverlight app. When they log in, I pass them a forms auth cookie just like any other site:

 FormsAuthen开发者_StackOverflow中文版tication.SetAuthCookie(userName, createPersistentCookie);

The XAP file is in the ~/ClientBin/ folder. The SVC file is in the ~/Services/ folder. Anonymous access is blocked:

<configuration>
   <system.web>
     <authorization>
       <deny users="?"/>
     </authorization>
   </system.web>
</configuration>

The Silverlight calls to the SVC results in a HTTP 302 bouncing back to the login page, and crashing the Silverlight. :( This only happens when anonymous access is disabled. I think Silverlight is NOT passing the cookie along with the WCF service call. Why not?

I made sure to use the AspNetCompatibilityRequirements as defined within the documentation (http://msdn.microsoft.com/en-us/library/dd560702(VS.95).aspx):

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class TaskSchedulerService : ITaskSchedulerService
{

and my web.config has

<serviceHostingEnvironment aspNetCompatibilityEnabled="true"
multipleSiteBindingsEnabled="true" />
</system.serviceModel>

The same thing happens using basicHttpBinding or customBinding with BinaryCompression enabled.

---

Good news! I found the issue... My silverlight application was programmed such that it would inject a dot "." into the URL when it called the web service on localhost (http://localhost/myservice.svc -> http://localhost./myservice.svc).

I purposefully added this extra DOT so I could debug local traffic with fiddler. I removed the dot, and authentication works! The extra dot was percieved as a separate domain.

It turns out that WITH INTERNET EXPLORER 9, FIDDLER CAN DEBUG LOCAL TRAFFIC WITHOUT THE DOT.

As the MSDN Dcoumentation says:

To use the service from a Silverlight application, no special steps are required. Invoke the service in the same way as you would invoke a non-secure service. When calling the service, if the user is not logged in to the ASP.NET site that hosts your Silverlight application, or if the user is not authorized to call the service, an error will occur. Thus, it is especially important to gracefully handle error conditions when using secure services.

Bottom line: if you are developing silverlight, IE9 is your best friend.