Wouldn't the problem be solved for SDS if the SDS team enabled uploading a clientaccesspolicy.xml to the root of the authority?

Also, it is worth pointing out requests to SDS using basic authentication are done over SSL (https). That's not terribly insecure.

The solution for that is to setup a reverse proxy on your domain that will hit the Azure datastore.

I like Ayende's idea of the reverse proxy. Aside from working against the current bits, it also would provide a layer where you can better manage security and access to the datastore.

James,

The problem is that the ADO.NET Data Services Library doesn't work cross domain *regardless* of a client policy file. Its a technical issue with the http stacks that are available to Silverlight not SDS's fault.

Ayende,

Yes a reverse proxy would solve this and if you are hosting your server in Windows Azure this is a good solution (as the reverse proxy would be efficient because its access SDS across an efficent network stack), but if you are hosting your server code outside of Azure (as most will) the reverse proxy will be inefficient (two Internet hops to make every request). It works, just inefficient. Depending on your app that is either critical or trivial.

Shawn,

I don't believe SDS is using an Astoria front-end yet; the Astoria front-end is an incubator project that hasn't yet been released.

SDS's current front-end is the same as SSDS's: SOAP or REST. For more details see http://oakleafblog.blogspot.com/2008/10/sql-data-services-sds-test-harness.html and http://oakleafblog.blogspot.com/2008/10/inq-and-entity-framework-posts-for.html#Astoria (includes a comment by Pablo Castro.)

Not sure if this fixes the cross-domain problem, however.

--rj

Shawn:

The cross-domain issue is one of the main reasons I started my SDS-Proxy project. This is a thin ASP.NET Handler that can live within your own domain space and then talks directly to SDS via HTTP. It also has some advantages as it does more aggressive caching (cuts down on traffic to SDS servers) and 'normalizes' some URLs to make it easier to do cross-container even cross-authority calls.

Check it out here:
http://amundsen.com/examples/ssds/

There are links to the source code there, too.

Hi, not related but seems that all the links on http://www.silverlightdata.com/ are broken...?

Also, RJ, FWIW:

Accessing SDS via the Astoria 'interface' is fairly lightweight from the HTTP/REST side right now. for example, getting a list of entities looks like this:
http://[authority].data.database.windows.net/adods/v1/[container]/Entities()

Pass the Accept header of "Accept:application/atom+xml"
or
"Accept:application/json"
to control the serialization format

As you pointed out, this is highly 'experimental' and there are lots of loose ends (query format is not LINQ-y), but at least it's easy to pull.

Mike Amundsen,

Good info but the double-hop problem might make going to SDS especially slow. But I'd love to see it when you have something (You might want to consider it for the SilverlightContrib project).

Hmm interesting. But when reading the full documentation of SQL Data Services, I found about another authentication method SDS supports. It's Token-based authentication (username, password), I haven't tried this, yet. But it sounds interesting.

http://msdn.microsoft.com/nl-nl/library/cc984285(en-us).aspx