Posts Tagged ‘Office 356’


The name “apps for SharePoint” is changing to “SharePoint Add-ins” & its official (https://msdn.microsoft.com/en-us/library/office/fp179904(v=office.15).aspx#Minor). Any references to the app with-in the SharePoint eco-system will now be termed as Add-in. This is not limited to SharePoint but also Office.

But why this change? Some reasons we get from experts,

  • Microsoft’s multi-platform support of Office client across the Windows/Mac, iOS, Android and Windows 10 environments ended terming the Office client as “apps”, and so having “apps” within “apps” was causing confusion
  • Microsoft received multiple feedback that “apps” weren’t working in the enterprise space who were building something that was valued at much more than a simple app.

The notion also needed to be consistent here with the name change across both Office & SharePoint for the Office Store perspective.

Whatever may be the reasons, we just need to update our pointers from Apps to Add-ins. Below is the table that might help you to do that.

Original name New name Applies to
apps for Office Office Add-ins Office
mail app for Outlook Outlook Add-in Office
app for Excel Excel Add-in Office
app for PowerPoint PowerPoint Add-in Office
app for Word Word Add-in Office
apps for SharePoint SharePoint Add-ins SharePoint
app part add-in part SharePoint
app web add-in web SharePoint
SharePoint App Model SharePoint Add-in Model SharePoint
SharePoint Hosted App SharePoint Hosted Add-in SharePoint
SharePoint Provider Hosted App SharePoint Provider Hosted Add-in SharePoint

​There are three types authorization policies in SharePoint 2013. This post explains what each of this means and where exactly these are used.

AppAuthPolicies

 

User-Only:

This was the policy which was there in 2010 too. Whenever your code gets executed, only the user permissions are considered. If the user have the rights to do what the code have to do, it executes fine. There is no other authorization required.

 

User + App:

As you start coding your SharePoint apps, you will come across the terms like App Manifest, App permissions etc.,  where in you mention certain permissions your app needs to execute the code it contains. Some of such permissions levels are (Read, Manage etc,). In this case, when your code gets executed, the app should have the required permissions & also the user whose context the app is getting executed should have the same level of permissions.

For example, in case your app is trying to update an item in a list in your host web, your app may have Write permissions  but if your user is having only Read permissions your code will not execute & vice-versa. So both your app and the user should have Write permissions for the app to work.

To put it simply both your user context and app context are taken in to consideration here.

 

App-Only:

If at all a timer job can be made possible for SharePoint online, then it’s using this authorization method.

This method allows you to execute code even if the current is not having the required permissions. We will not be able to elevate/provide every user the required permissions. But we need to perform an action that the user is not entitled to. People always consider this as a replacement for RunWithElevatedPrivileges in farm solutions. But it’s not. This is not same as RunWithElevatedPrivileges. RunWithElevatedPrivileges still takes the current user context in to consideration. But in this case we ask the app to totally ignore the user context.  This is done by adding the property AllowAppOnlyPolicy=”true” to your app manifest file. Below will be the permissions you will see in the manifest file.

<AppPermissionRequests AllowAppOnlyPolicy=”true”>

<AppPermissionRequest Scope=”http://sharepoint/content/tenant&#8221; Right=”Manage” />

</AppPermissionRequests>

In general, a current user is required to be present for a call to be made. In the case of app-only policy, SharePoint creates a SHAREPOINT\APP, similar to the existing SHAREPOINT\SYSTEM user. All app-only requests are made by SHAREPOINT\APP. There is no way to authenticate as SHAREPOINT\APP through user-based authentication.

Since app-only calls effectively does what a user is not meant to do , you should be conservative in creating apps that ask for permission to make them. Calls should use the app-only policy only if:

  • The app needs to elevate its permissions above the user for a specific call; for example, to approve an document under conditions evaluated by the app.
  • The app is not acting on behalf of any user; for example, an app that performs nightly maintenance tasks on a SharePoint document library.