Silverlight RIA application using services from different web site - deployment

Question

I have a Silverlight application that uses both a RIA authentication domain service and a RIA entity domain service. The application works properly when run in a standard deployment scenario where the RIA services are consumed from the same ASP.Net web site that the Sivlerlight app is downloaded from.
In order to make my deployments more flexible I'd like to use separate web applications for hosting the RIA services and to host the Silverlight application. I've managed to get the RIA services working in a separate site and updated my Silverlight application to point to them. The problem is the authentication seems to break. I've looked at the RIA requests in fiddler and the authentication cookies are seemingly correct.
Has anyone managed to deploy a Silverlight RIA application with the RIA services hosted on a web site different to the one the Silverlight app is downloaded from?

Answer 1

Edit: this won't help you either.
http://msdn.microsoft.com/en-us/library/ee707359%28v=vs.91%29.aspx
The domain context class contains three constructors:
A default constructor that embeds the URI necessary to communicate with the domain service over http using a WebDomainClient class.
A constructor that permits the client to specify an alternate URI.
A constructor that permits the client to provide a custom DomainClient implementation (typically used for unit testing or redirection to a custom transport layer).

Answer 2

In the end the only difference I used fiddler to look at the difference in the requests that were working for a self hosted RIA service and an external one and the only difference was the HTTP referrer header. It would seem strange that the RIA RequiresAuthentication attribute takes the referrer header into account so perhaps it's something else entirely.
I was able to find a way to consolidate my domain and authentication services into a single one and allow it to be hosted on a different web app which is very handy. The approach was to put the AuthenticationDomainService into the main domain service. It doesn't allow the same usage pattern on the client, authentication is an entity load operation, but it does still make it easy to use an ASP.Net membership provider for authentication.
[EnableClientAccess]
public class MyDomainService : LinqToEntitiesDomainService<MyEntities>, IAuthentication<User>
{
public class AuthenticationDomainService : AuthenticationBase<User>
{ }
private AuthenticationDomainService m_authService = new AuthenticationDomainService();
public User Login(string username, string password, bool isPersistent, string customData)
{
return m_authService.Login(username, password, isPersistent, customData);
}
....