This post is article 19 from the 30 Articles App series for SharePoint

In this article, I will discuss about Cross-Domain Calls, what are they and how to make it happen for Apps.

What is Cross-Domain Call?

As the name suggests whenever an app/programme wants to make client-side calls (for example, using JavaScript + XMLHttpRequest) from a page hosted in one domain (for example, http://www.domain_1.com/appPage.html) to a page or service hosted in a different domain (for example, http://domain_2.com) , it is called Cross-Domain call.

Cross-Site Request Forgery is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf, like change the victim’s e-mail address, home address, or password, or purchase something. these type of attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

By default, browsers block this type of communication for security reasons; they don’t want malicious apps to grab data or execute code without users knowing it. 

What to do when your app actually wants to make safe and trusted cross-domain call?

The App model for SharePoint and remote-hosting options easily put developers to face cross-domain challenges.  So how to achieve this trusted and secure connection? Well SharePoint offers Cross-Domain JS library SP.RequestExecutor.js which you can find in LAYOUTS directory. By utilizing this library, your app can incorporate information from SharePoint into your app and from your app it’s been utilized it to other web apps.

How does it actually work?

Behind the scene this JavaScript library uses hidden IFrame, PostMessage and proxy page to take care of making secure connection to SharePoint. This proxy page is responsible for forwarding calls to the underlined SharePoint infrastructure.

Your app will also need permission to make cross-domain calls and also have to have registration for the “allowed domains”.

Check the next article to know more about how to implement cross-domain calls in SharePoint Apps.

This post is article 18 from the 30 Articles App series for SharePoint

In this article, I will discuss about tenancy , app scope and how does that affect the app.

What is Tenancy?

A Tenancy in SharePoint 2013 is a set of site collections.

In SharePoint Online (ex. O365 SharePoint environment) this set of site collections belong to a single customer account.

For on-premise, it could be all of the site collections from the web application, some of it or it can be from multiple web applications as well.

A tenancy can have an app for SharePoint app catalog just as a SharePoint web application can.

What is App Scope?

Tenant administrators can decide the app scope for an app either tenant scope or web scope.

App scope is neither the feature scope nor the app permission levels used while developing the app.

If the app is uploaded to the SharePoint app catalog of a tenancy, it is available to all the websites within that tenancy. It can be installed website-by-website basis. App installed this way have web scope.

If Tenant administrator batch install the app to a subset of websites within the tenancy, then the apps have the tenant scope. Tenant administrator can decide on which websites within the tenancy the app can be installed.

The interesting part comes here 🙂

If an app that includes an app-web is batch-installed, only one app web is created and it is shared by all the host websites on which the app is installed. The app web is located in the site collection of the corporate app catalog.

So you as an app-developer cannot decide the app scope. Only the tenant admin can choose the app scope by choosing the relevant deployment method for the app.