Host webs, app webs, and SharePoint components in SharePoint 2013

apps for SharePoint

Learn about the distinction between host webs and app webs. Also find out which SharePoint 2013 components can be included in an app for SharePoint, which are deployed to the host web, which are deployed to the app web, and how the app web is deployed in an isolated domain.

Last modified: January 07, 2014

Applies to: apps for SharePoint | Office 365 | SharePoint Foundation 2013 | SharePoint Server 2013

When an app that includes SharePoint components is installed on a website, it is listed on the Site Contents page from which it can be launched. That listing, which is the launch point of the app, is the only required addition to the website, although certain other things can optionally be added, such as a custom action or an app part. For information about these options, see Accessing the app from the UI. Other than these UI elements, the app for SharePoint components and content, such as lists, content types, workflows, and pages, are deployed to a different website in a special isolated domain. This fact is largely hidden from the user. The special website to which the app is deployed is called an app web. The website to which the app is installed is called the host web. Although the app web has its own isolated domain, it is in the same site collection as the host web. (One exception to this rule is when the app is installed with tenant scope. In that scenario, the app web is in the site collection of the corporate app catalog.)

Figure 1 shows a host web with two apps for SharePoint installed. App 1 has remote components, but no SharePoint components, so it has no app web. App 2 has no remote components, but it has two SharePoint lists and a workflow. These have been deployed to an isolated subsite. (An app for SharePoint can have both remote and SharePoint-hosted components, although neither app in this diagram has both.)

Figure 1: Host web with a cloud-hosted app and a SharePoint-hosted app

Host web, app web, and their components.

For example, suppose that an app, with SharePoint components beyond just the UI elements that can be deployed to a host web, is installed on a host website at the following URL:

https://www.fabrikam.com/sites/Marketing

The app for SharePoint will be deployed to a newly created website with a URL like the following:

http://app-bdf2016ea7dacb.fabrikamapps.com/sites/Marketing/Scheduler

Note that this URL has the following structure:

https:// App_Prefix - App_ID . App_Base_Domain / Domain_Relative_URL_of_Host_Web / App_Name

The placeholders are defined as follows:

  • App_Prefix is any string set by the farm administrator in Central Administration. The default is "default." In this example the administrator has changed this to "app."

  • App_ID is a hexadecimal number generated internally when the app is installed.

  • App_Base_Domain is any string set by the farm administrator in Central Administration or with SharePoint Management Shell. This should not be set to a subdomain of the SharePoint web application or the purpose of app isolation is largely defeated. In this example, the administrator has removed the "www." and added "apps" to the company name. So fabrikamapps.com is the app base domain.

  • Domain_Relative_URL_of_Host_Web is the relative URL of the parent host web, in this case sites/Marketing.

  • App_Name is the value of the Name attribute of the app element in the appmanifest.xml file.

There are two primary reasons why SharePoint components are deployed to app webs, rather than the host web. Both are related to security.

  • Enforcement of app permissions: In the model for apps for SharePoint, an app has its own identity and it has permissions that are not necessarily the same as the permissions of the user who is executing the app. These app permissions are requested when the app is installed and granted by the person who installs the app, as long as person has all the permissions that the app requests. (If the user who is installing the app does not have all the permissions that are requested by the app, the user cannot install the app.) By giving each app its own domain, SharePoint 2013 can reliably identify requests made by the app and verify the permissions of the app. For more information about app permissions, see App permissions.

  • Cross-domain scripting security: Modern browsers support a "same origin policy" with regard to JavaScript method calls. By deploying each app for SharePoint to its own domain, SharePoint takes advantage of the browser's same origin policy to ensure that JavaScript in the app for SharePoint cannot execute any JavaScript from any other domain, including the domain in which, from the end-user's perspective, the app is installed.

    SharePoint also provides a means of safely overcoming the limits of the policy. Among other things, this enables the remote components of an app for SharePoint to query data from any website in the common parent tenancy of the host and app webs. For more information, see How to: Access SharePoint 2013 data from apps using the cross-domain library.

In general, an app for SharePoint can contain one or more of the components in the following list. With certain exceptions, these components must be deployed in Web-scoped Features that are inside a SharePoint solution package (.wsp) file:

Note Note

* The components that are marked with an asterisk (*) are discussed in more detail in the section Caveats for deploying SharePoint components later in this article.

  • Features (Web-scoped only)

  • Custom actions (including shortcut menu items and ribbon customizations)*

  • Remote event receivers*

  • Markup that references Web Parts, including app parts, that are included in SharePoint (but not custom Web Parts)*

  • Custom cascading style sheets (CSS) files for use by SharePoint pages

  • Custom JavaScript files for use by SharePoint pages

  • Modules (sets of files)

  • Pages

  • List templates

  • List and library instances

  • Custom list forms

  • Custom list views

  • Custom content types

  • Fields (of field types that are built into SharePoint)

  • Microsoft Business Connectivity Services (BCS) models (Web-scoped only), external content types based on the model, and external lists that use the content types*

  • Workflows*

  • Property bags

  • Web templates (but not site definitions)*

No other kind of SharePoint component can be deployed in a app for SharePoint. For more information about restrictions on what can be included in a app for SharePoint, see Apps for SharePoint compared with SharePoint solutions.

The following are some caveats and details concerning the deployment of certain kinds of SharePoint components in an app:

  • Custom actions: In addition to adding custom actions to the app web, you can add them to the host web as well. To add the custom action to the app web, you include it in a Web-scoped Feature that is inside a .wsp file, just as you would include any other component you add to the app web. To add a custom action to the host web, you can include (even in an externally based app) CustomAction markup in a Feature that is in the app package but outside any .wsp file. Components in such a "loose" Feature apply to the host web, not the app web, so this type of Feature is called a host web Feature.

  • Web Parts: One kind of Web Part, an app part, can be deployed in an app, and an app part can go to either the app web or the host web. All other types of Web Parts can be referenced in apps, but not deployed by them. If an app part is deployed to the host web, it should be included in a host web Feature.

  • Remote event receivers: These are new in SharePoint 2013. They resemble classic SharePoint event receivers except that the code runs in the cloud. These are not available in a SharePoint-hosted app.

  • Workflows: Workflows in SharePoint 2013 use the Microsoft Azure-hosted workflow runtime that is new in SharePoint 2013. Coded workflows that use the SharePoint-hosted workflow runtime cannot be included in a app for SharePoint. Only declarative workflows or workflows that use the newer runtime are allowed.

  • Microsoft Business Connectivity Services (BCS) models, external content types, and external lists:Business Data Connectivity (BDC) service models typically have a scope that is wider than a site collection. However, when a Business Data Connectivity (BDC) service model is deployed in an app, its scope is limited to the app web. When a Business Data Connectivity (BDC) service model is included in an app, it is not stored in the Business Data Connectivity (BDC) service shared service store. Instead, it is stored as a file in the app web.

  • Web Templates: In most cases, you will want the app web to instantiate the new built-in site definition configuration APP#0, which is optimized for app webs. (For more information about it, see Accessing the app from the UI.) SharePoint 2013 automatically uses APP#0 when the app package does not include a WebTemplate element.

    You can also define a custom site type for the app web. There are two major steps to doing this:

    Note Note

    The new WebTemplate element for app manifests is not the same markup as the WebTemplate element that can be included in Features. The WebTemplate element that can be included in Features defines a type of site, but the WebTemplate element for app manifests simply identifies what type of site to use. For more information about the app manifest of a app for SharePoint, see App package structure.

    Caution note Caution

    Do not use the WebTemplate element in the app manifest to designate any of the built-in SharePoint site definition configurations as the app web's site type. We do not support using any of the built-in site definition configurations, other than APP#0, for app webs.

    For more information about site definition configurations and web templates, see Working with Site Templates and Definitions.

Show:
© 2014 Microsoft