The importance of Cross Domain

Just today I came across some information related to cross-domain scenarios I shared in the past, and some hints for SharePoint 2013, so I decided to write a note ;)
Today, cross-domain is certainly one of the first class scenarios in web development.
One of our customers wanted to understand how to solve it in their solutions and then we talked about the cross-domain pattern, and how there are several projects that implement it.
Although in the past we have detailed information about it. From Using the Client to Bridge to External Services:

When you implement your client-side logic in a Silverlight application, there are two approaches you can use to access services in other domains from the client. The first approach
is to deploy a service facade, or proxy, to the domain that hosts your SharePoint server. This allows your Silverlight application to access the service within its own domain and avoids any cross-domain issues.

You can also use this approach for JavaScript clients. The principal advantage is that the services facade can reuse the credentials associated with the browser session in order to
authenticate the consumer of the service. However, there are various disadvantages. The approach adds an additional "hop" to the service interactions. It can be complicated to preserve the identity of a user across a double hop to the service; for example, NTLM authentication cannot be used over a double hop. This approach also requires that you develop and deploy a services facade. If you are constrained to the sandbox execution environment,
you may also be unable to deploy this kind of server-side component. Therefore, the reference implementation does not demonstrate this approach.

The second approach is to use the Silverlight application to access the external service directly. As described in RIA Technologies: Benefits, Tradeoffs, and Considerations, the domain that hosts the service must define a client access policy (clientaccesspolicy.xml) file that permits access from Silverlight clients across domain boundaries. The Silverlight External Service interface in the reference implementation demonstrates this by deploying a service to a different port (which constitutes a different domain) on the SharePoint server.

This pattern was/is very important in the new apps for SharePoint, where we leverage this functionality with the cross domain library and indeed you can find it at all levels:SPWebApplication.CrossDomainPhotosEnabled just check out Wictor post!


By the way, one of the articles I found was the Secure Cross-Domain Communication in the Browser written by involved in the past in the  cross-domain in-browser communication channel API for Windows Live.