SharePoint Applications

With SharePoint Hosted Apps, everything including the app files are stored within SharePoint. When an app is installed to a site from the app catalog, a sub- site (sub-web) is created that stores the files that make up the app. This is usually referred to as an app web. Things like pages, java script, etc... When a user leverages the app within SharePoint, the client will automatically fetch the app contents from the sub-web and client processing occurs to render whatever the app does. In this case, it’s not possible to run servers side code and app processing occurs client side.

SharePoint Hosted Apps can be made up of Pages, Lists, Content Types, Workflows, Remote Event Receivers and Client App Parts. We will dig into each of these items in later articles.

With the app running in a totally separate web application there is separation between the SharePoint process and App process. While giving SharePoint Apps more power than Sandbox Solutions, the SharePoint team have still managed to maintain separation. This is done through a combination of more powerful APIs, better monitoring and management tools, and the deployment to a completely separation web app.

Some important notes are:

• SharePoint-hosted add-in components are hosted in an isolated add-in domain.
• SharePoint-hosted add-in gets authorized using Logged-in user privileges.
• SharePoint-hosted add-ins will support only HTML, JavaScript, and CSS to deploy code. It won’t support C# or Managed code.
• Relatively easy to create and deploy, so suits for small team productivity add-ins and business process automation with lower complexity business rules.
• SharePoint-hosted add-ins are best to use only when HTML, CSS, and JavaScript (JSOM, Rest API) can fulfill your business requirements.

"Provider Hosted Add-in" provides better flexibility for hosting various components of your "Add-in". If you want to create an application, you need to match your goals and requirements with the appropriate hosting pattern.

Provider Hosted Add-ins provide you two options through which you can interact with SharePoint:

1. JavaScript cross-domain library
2. OAuth

JavaScript cross-domain library

JavaScript cross-domain library allows you to interact with more than one domain from remote components of your add-in through proxy. Cross-domain library is a good option under following two conditions:

1. If client-side code and the permissions assigned to user in SharePoint are sufficient (Read permissions to library).
2. Whenever you are making remote calls through a firewall.

OAuth

OAuth is an open protocol that enables secure authorization from client applications (desktop, web, and mobile applications) in a manageable way. OAuth is required whenever you are calling into SharePoint from a web application that is remotely hosted and can’t use client-side code (HTML + JavaScript) exclusively.

While using Provider hosted Add-in with Azure (Cloud) web deployment and Office 365, you need ‘Microsoft Azure Access Control Service (ACS)’ as the trust broker between Azure (Cloud) Web and Office 365 SharePoint site. But while deploying add-in in ‘On-premises SharePoint 2013’ site, it needs Server certificates along with ACS to enable High-Trust between add-in and SharePoint. These certificates should be installed on SharePoint on-premises server to enable trust between add-in and SharePoint.