​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.

2014 in review

Posted: December 30, 2014 in Uncategorized

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 97,000 times in 2014. If it were an exhibit at the Louvre Museum, it would take about 4 days for that many people to see it.

Click here to see the complete report.


With “Apps” being the buzz word in SharePoint 2013, and if you could have started developing apps, you could have noticed that your App.js file starts with a statement as below:

“use strict”;

App.js enables you to access SharePoint objects using ECMAScript & the version being used is ECMAScript 5. ECMAScript 5’s strict mode is a way to opt in to a restricted variant of JavaScript. Strict mode is a way to introduce better error-checking into your code.

Strict mode makes several changes to normal JavaScript semantics.

  1. Strict mode eliminates some JavaScript silent errors by changing them to throw errors.
  2. Strict mode fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that’s not strict mode.
  3. Strict mode prohibits some syntax likely to be defined in future versions of ECMAScript.

 

Below are the most important restrictions when you use strict mode,

  1. Using a variable without declaring it
  2. Writing to a read-only property
  3. Adding a property to an object whose extensible attribute is set to false
  4. Deleting a variable, a function, or an argument
  5. Deleting a property whose configurable attribute is set to false
  6. Defining a property more than once in an object literal
  7. Using a parameter name more than once in a function
  8. Using a future reserved keyword as a variable or function name
  9. Assigning an octal value to a numeric literal, or attempting to use an escape on an octal value
  10. The value of this is not converted to the global object when it is null or undefined
  11. The string “eval” cannot be used as an identifier (variable or function name, parameter name, and so on)
  12. You cannot declare a function inside a statement or a block
  13. If a variable is declared inside an eval function, it cannot be used outside that function
  14. The string “arguments” cannot be used as an identifier (variable or function name, parameter name, and so on)
  15. You cannot change the values of members of the local arguments object
  16. “with” statements not allowed

Note : Browsers not supporting strict mode will run strict mode code with different behavior from browsers that do, so don’t rely on strict mode without feature-testing for support for the relevant aspects of strict mode. Strict mode code and non-strict mode code can coexist, so scripts can opt into strict mode incrementally.


SharePoint 2007 (MOSS) & SharePoint 2010 have an option of “Sign in as different user” in the menu at the right top corner of the page. Developers used this handy menu to test their customizations for different users by logging in with another account. But in SharePoint 2013, you will not be finding that  option. You just can sign-out from the site, re-open the browser & login again.

Not sure is it removed with a reason. But MS references say it is a problem with SharePoint 2013.

So, How do I login as different user to my SharePoint site? There are two ways you can do it:

1) IE’s “Run as different user” option

This is the way old method we used to start any application with a different credentials. That is by using the Run as different user option that will be visible if you hold the Shift key when you right-click a program icon.

Start Internet Explorer by using the Run as different user option, where you can provide the different credentials and then go to the SharePoint site.

2) Navigating to the close connection page

More simple way is to browse the close connection page. Hit the below URL in your browser where you have opened your site.

http://siteurl/_layouts/closeConnection.aspx?loginasanotheruser=true

You will be getting a pop up to enter the new credentials where you can sign in as different user.

Note : This option uses an unsupported browser feature which is unreliable and may causes other issues. Currently this option does not work in IE 10 and Safari.

 

Hope it helps.

 

2013 in review

Posted: January 6, 2014 in Uncategorized

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 80,000 times in 2013. If it were an exhibit at the Louvre Museum, it would take about 3 days for that many people to see it.

Click here to see the complete report.