Ask a questionAsk a question
 

AnswerCross-site collection data sources

  • Thursday, October 15, 2009 7:54 AMMcGeeky Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    I notice that SharePoint Designer does not support data sources that are cross-site collection. When I add a site collection URL to the data source none of the site's lists or document libraries appear.

    So, I tried a different approach. I created a data source that calls the Lists.asmx web service on the site collection. But this didn't return any items... until I set the username password manually on the data source. Then I was able to retrieve the lists items from a site collection that is different to the one I am in.

    The good news is I can now do cross-site collection data access.

    The downside to this is that the credentials of a user have to be hard coded in to the data source, and, the context of who you are logged in as is lost.

    Why does SharePoint Online not recognise who you are automatically and use your context when accessing data in other site collections from the same Online Services account?

    Thanks.

    Myles

Answers

  • Thursday, October 15, 2009 6:21 PMTroy Hopwood [MSFT]ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Data sources run on the server so they are not aware of the current logged in user. Because of this, you will need to include credentials for it to work.

    The solution to avoid including credentials is to use Silverlight instead. Since Silverlight runs in the client, it runs in the context of the current logged in user. A Silverlight control can then make calls via web services to other site collections within the same tenant and access data without requiring additional credentials.

All Replies

  • Thursday, October 15, 2009 6:21 PMTroy Hopwood [MSFT]ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Data sources run on the server so they are not aware of the current logged in user. Because of this, you will need to include credentials for it to work.

    The solution to avoid including credentials is to use Silverlight instead. Since Silverlight runs in the client, it runs in the context of the current logged in user. A Silverlight control can then make calls via web services to other site collections within the same tenant and access data without requiring additional credentials.

  • Thursday, October 15, 2009 7:30 PMMcGeeky Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi Troy. Thanks for your reply - but I need some further clarifications :)

    Regarding the data sources; on a technical note, just because they run on the server doesn't mean they won't know about your credentials. The user's context should be passed down to them. However, in the case of SharePoint Online it doesn't seem to be happening. Why is that?

    Accessing another site collection with Silverlight is effectively cross-site scripting which can be problematic. If the sign in tool is not being used, which many of our web only customers don't, then surely your security context would not get passed to another site?

    BTW. A lightweight approach over Silverlight is to use AJAX stlye methods for calling back to the server which can be accomplished with JavaScript only.

    Regards,

    Myles
  • Friday, October 16, 2009 12:46 AMTroy Hopwood [MSFT]ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    There is nothing unique in the code for data sources between SharePoint Online and SharePoint Server. Online and Server are running the same SharePoint bits.

    You are outside my area of expertise when asking why user context isn't passed down to data sources. We do have a securiy trimmer implemented which is what prevents you from searching across multiple site collecitons. I suspect either the security trimmer or our use of cert auth are the root cause here.

    As for the sign in client, I strongly recommend you use this at all times. The user experience is very cumbersome without it. To the point where we don't actually support the non sign in client scenario.
  • Friday, October 16, 2009 7:06 AMMcGeeky Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Thanks for your feedback Troy. The sign-in client does indeed help the user experience and I would recommend it myself in most scenarios; I do have some gripes with it, which I think you know about already :).