4

So I have been having this issue for awhile and im not sure what has changed. I used to be able to get the form digest value from hitting the /_api/contextinfo endpoint using a post call after signing into Sharepoint with the postman chrome app, but now it 403 ons me every time.

I found postman to be really useful for testing my urls before trying them out in my app, so fixing this problem would be a really big help for me.

2 Answers 2

5

So the issue as pointed out by Pete Rijks is that google is adding an Origin header to the postman request.

I had an old version of postman which didn't have the update notifications. Be sure to download the latest version which is around 3.0.2 at the time of this posting.

You will also have to download the postman intercept app as well. turn it on and then you will be able to apply your

Origin 

header which should come from the same domain as the SharePoint Site you are working on. If you cannot figure out how to turn on the interceptor visit the postman blog, but if you play with the UI buttons it should be self explanatory

Be sure to also include the

X-RequestDigest   

header as well which you will get from the

_api/contextinfo 

endpoint.

1
  • does this work for SharePoint on-premise ?
    – Light
    Mar 1, 2016 at 10:19
2

Are you using SharePoint Online? We encountered this same issue with SharePoint Online recently that it started returning 403 errors to requests that have the "Origin" header set, which is the case for Postman as well as a few similar Chrome apps such as "Advanced REST client" and "REST Console." Although it may be the case that it was the behavior of Chrome that changed and it only recently started adding the "Origin" header. In either event, the Origin header is what is causing the issue.

I haven't figured out a way to disable Chrome from sending the Origin header, although there may be a way, I didn't do too much research. My workaround has instead been to use SoapUI (http://www.soapui.org/) to do my SharePoint REST testing. Note that it isn't as friendly a solution, and if you're using SharePoint Online, you'll need to log in with your browser and then copy the cookies and add them to the headers being sent by SoapUI. But the advantage is that you're in full control of what headers SoapUI sends, unlike with Chrome.

Another option that I haven't tried myself would be to use a Firefox plugin instead. I read that Firefox doesn't send the Origin header in as many cases as Chrome does, and there do exist REST client plugins for Firefox. But again, I haven't tried that myself as SoapUI works for me.

Hope that helps.

4
  • 1
    As another note: the problem is that the value Chrome fills in for the Origin header does not match the SharePoint URL - e.g. I just tested setting Origin to https://redacted.sharepoint.com/ in SoapUI and the request worked fin. But Chrome sets Origin to chrome-extension://somestring and when I use that Origin in SoapUI I get the 403. Unfortunately, if I set the Origin manually in Postman, it still gets overridden by Chrome.
    – Pete Rijks
    Jun 11, 2015 at 16:28
  • thanks man I will have to give SOAPUI a try. it has been really slowing down my development not being able to use this app anymore. Not to mention I need to learn the web protocols for headers. I'm getting tired of putting all of my eggs into the google basket so I think I may change to develop in firefox.
    – McFrank
    Jun 12, 2015 at 11:34
  • While this solution may work, I actually got in contact with an old co-worker who read your post and was able to find a way to get postman working again
    – McFrank
    Jul 7, 2015 at 15:08
  • Awesome, thanks for posting the follow-up, that's good to know!
    – Pete Rijks
    Jul 7, 2015 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.