SharePoint 2013 – Integration Challenges – #3 Same Origin Policy & Authentication – Cross-Domain Library


I’m currently involved in integrating SharePoint with IBM Connections and I’m having a lot of fun trying to figure out all the possibilities. Since these integration considerations are not specific to SharePoint/IBM Connections, I’ll blog a series of posts which will be rather short or rather long according to the topic I’m focusing on.In this post, I’m going to focus on the SharePoint Cross-Domain library which turns out to be suitable only in some scenarios.

Read this one first

Make sure you read this post first

Only Apps

Whether you use SP.WebProxy or SP.RequestExecutor or _api/SP.WebProxy.invoke, the only way you can get this to work is by calling those objects from within an App. If you try to use them outside of an app context, you’ll get a very straigt forward message : Calls to WebProxy without an app context are not allowed.

Using SP.WebProxy, you can indeed bypass the same-origin policy problem. The only thing you have to do is to specify which RemoteEndPoints can be targetted in the AppManifest. Also, depending on whether your endpoints are internet facing or intranet facing, you might need to set disableintranetcallsfromapps to false in order to allow intranet calls.

However, if you target a non-anonymous system, you’ll have to handle authentication and the out of the box proxy isn’t of a great help on that matter.

While IBM Connection’s built-in cross-domain proxy offers to forward cookies such as the LtpaToken2 and to specify HTTP Headers right from the proxy-configuration file and also offers a native support of SSL certificates (self-signed included), SharePoint doesn’t seem to have similar possibilites.

So, the cross-domain library is easy to use for anonymous scenario, if you have to authenticate, you can always add some header information via the set_headers method of SP.WebRequestInfo. However, for that to work correctly, you need to retrieve the user information of the remote domain (which is almost impossible). If you have a SSO solution in place, you might want to forward either an authorization header, either some cookies, either a client certificate but again, from JavaScript, it’s not the easiest task.

So, in my scenario, I only needed to find a solution for development since the production solution will consist in having client certificates containing some header information and automatically forwarded using F5. But I don’t have any F5 in development environments….

Fiddler to the rescue again

If you still haven’t read it, go read this post which basically explains how to script rules in Fiddler to forward the authentication cookies to the remote system.
In this case, I’ve added a new rule :

if(oSession.oRequest.headers["X-Forwarded-For"] != '' )

which basically detects requests that are forwarded by the App Proxy by checking whether the X-Forwarded-For request header is present or not. When present, Fiddler adds IBM Connections cookies to the target request which authenticates the user against IBM Connections.

So, this technique is only valid for a development environment.

What about a custom proxy

Unlike SP.RequestExecutor, SP.WebRequestInfo doesn’t come with a custom proxy hook so it’s useless to investigate further that lead. What you can always do of course, is writing a FARM solution that deploys a service/page that acts as a proxy.

That could be used from within Apps and from non-Apps but again, the challenge is to authenticate the user against the remote domain. This scenario can also be a good fit when targeting anonymous remote resources or when able to work with a technical account. It could also be a good fit for SharePoint inter-web application talk.

Happy Coding!

About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in Javascript and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s