Accessing caller web in SharePoint hosted app (SP2013 Preview)

Wednesday, 15 August 2012

SharePoint apps are hot topic these days, after Microsoft announced that they will be preferred development model for next major version of SharePoint products – known as SharePoint 2013. Applications will be purchased/downloaded from Office Store, or from corporate application catalog. There are 3 application models, depending on the fact where the real app code is hosted:

  • provider-hosted app

  • autohosted app

  • SharePoint hosted app

In first two cases, application code is hosted outside of SharePoint, on some kind of remote server, either on classic hosting (provider-hosted) or in Windows Azure (autohosted). In these two cases, application communicates with SharePoint using SharePoint CSOM or by using REST to access data stored on SharePoint. They can be developed using any server-side technology which supports REST for the purpose of communication with SharePoint for data manipulation.

In third case, when application is hosted on SharePoint, it is actually hosted on dedicated SharePoint web application and isolated from the caller SharePoint web. Specific to SharePoint hosted apps is that they support only client-side technologies for development, which means that they are intended to use JavaScript client-side object model libraries in SharePoint 2013. Microsoft also announced web-based development tools for SharePoint 2013/Office app development, called “Napa app”.

One of first how-to articles on MSDN related with SharePoint 2013 describes creation of the SharePoint hosted application using “Napa” which is using JavaScript CSOM to manipulate content of SharePoint web – creating and deleting lists, adding and deleting list items. In this article, scenario is set up in such a way that all content (lists and list items) which the app is using is stored in SharePoint web dedicated to this app – and the app references ClientContext by using get_current() method in ClientContext constructor:

context = new SP.ClientContext.get_current();

For development and testing, I am using Office 365 Developer subscription preview – which is the proposed way of development apps for SharePoint 2013 in case one don’t have server infrastructure needed for running SharePoint 2013 (CPU, RAM and other requirements are higher than in SharePoint 2010 timeframe). In my case, all apps which I develop, are deployed to my online Developer subscription and tested there. I wanted to be able to access and manipulate the data stored on that SharePoint web, as opposed to the scenario which is described in the how-to article. In order to accomplish this, two steps are necessary:

  1. ClientContext constructor has to be modified in order to access my caller web. In this step I’m not using get_current() method, but instead adding server relative URL to my caller web (in this case, it is root web) like it was normal practice in SharePoint 2010 JavaScript CSOM:

context = new SP.ClientContext("/");

After introducing this change, if you try to run your app immediately, you will encounter Access Denied error, or you will receive login prompt. Because of that, you need to perform next step.

  1. Check if the application has proper permissions, by looking at AppManifest.xml using “Napa” or Visual Studio. In order to perform operations which are subject of this how-to, application need to have at least “Manage” permissions to caller web, and AppManifest needs to have this code:

If this code is missing, you can add it – in Visual Studio 2012 there is a support for AppManifest designer which is providing nice interface on top on this XML.

After performing these two steps, SharePoint hosted app created using JavaScript will be able to access and manipulate content in the caller web.

Disclaimer This example shows technical solution for accessing caller web content from SharePoint hosted app in SharePoint 2013. It is not analyzing whether this is a good practice or not, and honestly, I am not sure if such an app could successfully pass app verification process, because app is messing with caller SharePoint data. Use it at your own risk.