Why write this post?
A colleague of mine at work came at me with a problem with one of his Workflows he was authoring in SharePoint Designer 2013 (SPD) against #SharePoint 2013 Server On Premises. Now before you say “… well that is what you get for using SPD”, he had to use it because of the Client policy, i.e. No Visual Studio Solutions. So, what is the problem right… here is a summary of the email below.
Now, I think here would be the perfect place to say thanks to Jeremy Thake @jthake and Mauricio Ordonez at Microsoft who gave me a much better understanding of the process of how the XML that you use when Adding an App Step as described in this MSDN article here actually works. Now, Ive always used this at the Site Collection Level never in a Sub Web and Ive always targeted the “Current” web, you will see what this is important later on in the post. However, if you read the documentation in the post as it talks about the XML needed for the App Permission and Scope, you are told to copy it as is.. which one does right 🙂 think im fibbing? Read the cautionary note.
Now the fact that I am doing this at the SC Level, and i see …/sitecollection/web and it works.. I “mistakenly” thought that this would work if I used it ‘unaltered’ in the Sub Web making a call to the Parent Web…And this is why you are here and still reading. so…
Observed Error
I have noticed an issue working with SharePoint Designer 2013 Workflows when you are in a Sub Web making calls to the Parent Web. A colleague of mine experienced this and I was able to replicate it, I wonder if anyone else has seen this and have any thoughts on the matter.
1. Open SPD 2013 targeting a Sub Web – https://x.sharepoint.com/sites/ParentWeb/SubWeb
2. Make a HTTP Call Activity to the parent web https://x.sharepoint.com/sites/ParentWeb/_api/web/Title
3. You get an Unauthorized as the response code coming back
What Works using SharePoint Designer 2013
-
- From the Parent Web you can make use HTTP Call Activity the call to https://x.sharepoint.com/sites/ParentWeb/_api/web/Title i.e. the same Parent Web
- From the Sub Web you can make use HTTP Call Activity the call to https://x.sharepoint.com/sites/ParentWeb/SubWeb/_api/web/Title i.e. the same Sub Web
What Does NOT work “with” or “without” using the App Step
-
- Parent Targeting Sub – From the Parent Web trying to make use HTTP Call Activity the call to https://x.sharepoint.com/sites/ParentWeb/SubWeb/_api/web/Title
- Sub Targeting Parent – From the Sub Web trying to make use HTTP Call Activity to https://x.sharepoint.com/sites/ParentWeb/_api/web/Title
- Top Level Targeting another Top Level – i.e. https://x.sharepoint.com/sites/SC1 trying to use the HTTP Call Activity to call https://x.sharepoint.com/sites/SC2
What is striking is that I can make all these call outside of SharePoint by using Fiddler, CSOM, Managed Code etc. but that is not in the context of running inside SharePoint like a SPD Workflow… any thoughts?
Eventual Resolution
So there are two things going on here in this XML
1: <AppPermissionRequests>
2: <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />
3: </AppPermissionRequests>
First, Scope, which managed where you are targeting this App Step to work and Second, Rights, which tell the App Principal what it can do in that Scope. Here is what I know to be TRUE after I have tested a few Scenarios
-
- If you set the XML above to the below.. KEY Thing here.. the /web is gone from the Scope URI
- If you set the XML above to the below.. KEY Thing here.. the /web is gone from the Scope URI
1: <AppPermissionRequests>
2: <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />
3: </AppPermissionRequests>
- You will be able to
- Open SPD in a Parent Site Collection and use a HTTP Call to Target the Parent SC and any Sub Web Beneath it
- Open SPD in a Sub Web and and use a HTTP Call to Target its Parent Site Collection Above it
What I HAVE tried and Still get a Unauthorized i.e. still don’t work
- Open SPD at any Level (Site Collection Parent or Sub Web) and use a HTTP Call to Target a “Different” Site Collection
But I understand why… let me break it down by the numbers
- When you open up SharePoint Designer and specify a URL anything you do is Scoped at that Level, however you can as in the case of Workflows use the “App Step” [which by the way only becomes an available option after you implement this MSDN article here ] you can use the Workflow App Principal and target other Levels.
- That’s the pickle isn’t it…
- When you do http://{hostname}/{catalog site}/_layouts/15/appinv.aspx to set up the XML Scope and Rights you are already tied to that Url arnt you? so…
- When you open up SharePoint Designer in another Web it DOES NOT KNOW about the App Principal Workflow of the one you did in a separate Site Collection or Site Collection/Sub Web ergo…
- you will Always get an Unauthorized
So.. that being said, let me show you a few screen shots with explanatory notes.
Summary
So I guess if one were to ask me what is going on I would say… “it seems that the URI in the scope is set to scope at the Level you specify and Look Downward and UP TO that level you scope it at”. Even though when I open SPD up at a Top Level Site Collection and have the XML URI scoped to /web I can see only that current Web even though it is a Site Collection FURTHER, if I am at a Sub Web in that Site Collection I can only see that Sub Web. If However I set the XML URI to scope at /sitecollection I can see the entire Site Collection and any Sub Web from anywhere in the SC.
Lets take a look at this procedurally to make it work as I did it.
First you need to follow the MSDN article here and below what you are seeing is
I’m targeting the Site App Permission in the Sub Web
I go through the entire thing of taking the App Principal GUID of the Worfklow and set my XML to be scoped to Scope=http://sharepoint/content/sitecollection/ Right=”FullControl” then I trust what I have just done.
Next I open up SPD, if you already have it open you will notice that your “App Step” is greyed out, you need to shut down SPD and re-open it for it to pick up the change. What you see below is the App Step Invoked from in my Sub Web (SPC14) and I have 2 “Regular Steps” inside my “App Step”
- Reading from the Parent Web and will Log out accordingly
- Reading from the current Sub Web and will Log out accordingly
Just showing you the Headers
Next showing you the HTTP Call to the Parent Web from within the SPD opened up Sub Web
Next showing you the call to the current Sub Web
Next this is the workflow as it was ran…
I sincerely hope that this helps you in your efforts. Im often reminded that “Everything is EASY once you know it!” I thought I “knew” this but there is always more to learn.
Cheers. & Irie.
This is the expected behavior. The workflow is nothing but a provider hosted app. That said, when you make calls to SharePoint from the workflow, the workflow engine automatically adds the “Authorization: Bearer…” HTTP header to every request. This header contains your OAuth access token and when the _api (==client.svc) endpoint in SharePoint receives a request with this header, it activates the app security model in which the app and the user permissions are combined and evaluated. If you omit the Authorization: Bearer… header, the app model security will not be activated and only the user permissions are taken into account – that’s why you didn’t have that problem when you were making requests from Fiddler or managed non-app CSOM code.
Regarding the scopes: the …/web scope means your app has access only to the SPWeb where it is installed (“the host web”) and to all its child elements (lists, …); the …/sitecollection scope means the app can access all SPWebs within the site collections where it is installed and if you want to be able to access other site collections, you have to upgrade to the tenant scope – then you can access all site collections within the tenant.
that is great feedback, and a good explanation. I eventually found this out from the MS Staff, I know it know though 🙂 thanks for sharing.
Thank you so much for this very clean and clear description of the issue. It has been hard to uncover the why’s and how to’s around using the new workflow action for cross-site HTTP calls to SharePoint web services.
Its been my pleasure, thanks for taking the time to write some feedback on the blog. I really appreciate it
Pingback: Office 365 Developer Podcast: Episode 004 Developer Panel Discussion | Office 365 Deployment Autoblog
Thank you for your post!!! It the problem I had with my workflow and trying to setup subsite auto creation.
Hi,
So its not possible to use POST and create a new list item in a list which is in another web application?
Yes it is but you have to provide Auth to open and write to that web application as well.
Hi Fabian,
I encounter Unauthorized when I call the user profile in Workflow for Sharepoint 2013. I use the call web http in SPD to call the User profile rest. However, I keep getting unauthorized. Is there a solution to it ? I saw some post saying giving Authorization empty in the request header helps but I still hitting the error.
I never tried the REST implementation, just writing to stupid list and libraries 🙂 However I don’t think UPS is POST, you may have to use CSOM for that, and I would not suspect leaving auth empty as the answer. For GETS it should work. I found this other blog post speaking specifically to UPS and REST http://www.vrdmn.com/2013/07/sharepoint-2013-get-userprofile.html
I found the solution that I do not need app step for this case. It works now without app steps. Thanks man.
Adrian – what was the solution? I’m facing the same challenge in Office365/Project Online.
Thanks,
Josh
Thank-you!!! I’ve been fighting the unauthorised reply on a REST call to create a site in a workflow and just removing the “web” part made it all work.
You are most welcomed. Happy to be of help
Pingback: Looping Through Content in a SharePoint 2013 Site Workflow – Part 1 – Setting Up App Permissions | Marc D Anderson's Blog
Pingback: Looping Through Content in a SharePoint 2013 Site Workflow – Part 2 – Setting Up App Permissions | Marc D Anderson's Blog
Thank You for this post!!!
Recently I was also struggling with Unauthorized error. Thanks to your post I was able to understand a lot but still one thing was missing: to perform operation in different site collection. The answer was in the scope of the XML: http://sharepoint/content/sitecollection and if you use: http://sharepoint/content/tenant the everything starts to works:)
References:
https://msdn.microsoft.com/en-us/library/office/fp142383(v=office.15).aspx
http://dinushaonline.blogspot.com/2014/07/cross-site-collection-data-access-via.html
Dawid – I could marry you right now! that small piece of information has enabled me to get around creating sites in different SC’s, without having to register the App credentials in every SC/Subsite individually. Thanks so much for sharing
Hello,
I have been trying to follow this blog and I have done all the required steps. I have created the app and its permissions using the scope=”http://sharepoint/content/sitecollection/” on Site Collection as well as Sub Site. However I am receiving response code=Forbidden.
We are running Project Online and the workflow is a list workflow on one of the Project Site (i.e. one of the sub sites).
Note: I made sure of writing the app permissions rather than copy/paste.
What do you think can be wrong?
Thank you and
Regards
Tanzim
Pingback: Creating subsites using REST API from SharePoint Designer Workflow « An Expected Error Has Occurred
Hi Fabian,
Great Blog Post!!
I have replicated the steps stated above but still my workflow is not being initialized on document creation. Just as a brief overview of my case, I have created a document library and given the members of the library only Add permission, which stops them from editing any files. Now when I try to upload the doc, the workflow never initiates. I was of the opinion that it would work if I kept my workflow content inside ‘App Step’
Thanks in advance!!!
Pingback: SPD Workflows and App Step – humanizing code
Excellent explanation, awesome post..Thanks, was very usefull
Excellent Work, Been looking at this issue all day,
{“error”:{“code”:”-2147024891, System.UnauthorizedAccessException”,”message”:{“lang”:”en-US”,”value”:”Access denied. You do not have permission to perform this action or access this resource.”}}}
As simple as changing the XML as above 🙂
Thank you very much your article is brilliant it help me save a lot of time. I followed your suggestion it worked!
My scenario have 2 sub site and a workflow at one sub site must HTTP call to update a site column of a document library in another sub site. Thanks again.
Sam
Thailand