1

We are developing an on-premise provider hosted add-in.

We would like to call the add-ins WebApi from JS code on a SharePoint page, avoiding app-parts (app part have several limitations).

We are facing authentication problems so we are not sure this is a possible path or either that we're missing something.

We want to be then able to have full SharePoint client context information in the WebApi server code side in order to be able to call SharePoint back using CSOM with the original call user identity.

1

May I suggest that instead of a Provider-hosted Add-in you use a WCF REST service instead. It is easy to build and deploy and, because it's hosted in SharePoint, it automatically picks up the identity of the calling user. You also get to use the Server Object Model instead of the Client Object Model.

I have a YouTube video showing how to build and deploy one of these services.

Building a SharePoint-Hosted WCF Service

  • as Rob mentioned, when i was told to create a web api in my recent on-prem-full-trust-code soln, i have created a wcf rest service , thats hosted in SP 2013 hive folder. [ 15 template layouts folder.] also the dll was deployed to bin folder,so no question arises about GAC as well. And its working fine as i was able to consume the same from a script editor web part using $.ajax() calls. – dasarp Apr 18 '17 at 6:15
0

I've done this a couple of different ways in the past: The easiest is to create a "dialog" which is actually a page on your "remote web". This dialog can be invoked via an ECB menu or the Ribbon. This dialog page will then be able to call your web service, avoiding cross-domain request problems. Then, you do an ajax call like this to your web service:

        $.ajax({
        url: "/<rest service uri here>",
        type: "GET",
        xhrFields: { withCredentials: true },
        success: function (data) {
    < your code here>
        },
        error: function (jqXHR, textStatus, errorThrown) {
            console.log(textStatus, errorThrown);
        },
        dataType: "json",
        timeout: 5000
    });

Note the use of the "withCredentials" call.

In your web service, you can use calls like ClaimsPrincipal.Current, User.Identity, Environment.UserName, etc. to get info on the current user.

Since the "dialog" is in your RemoteWeb, you can also get a "user client context" in the normal way, and the context will use those user's permissions.

If this doesn't work out (e.g. you really need to call the rest service from a SharePoint domain page, and not your Remote Web's domain page), you can also give your App/Add-in an "App Only" context. In the manifest of your .app file, you will need to add the "AllowAppOnlyPolicy" like this:

<AppPermissionRequests AllowAppOnlyPolicy="true">

You will need to re-deploy your app. Then, the code-behind for your REST call can get an "app only" context. It will also know the identity of the user using the standard windows calls given above.

Finally, I believe there is a way to have JavaScript in SharePoint that can make a cross-domain call to your remote web, but I can't remember how -- hopefully someone else here can put up such a sample.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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