3

I have created a SharePoint Add-In that attempts to list out the subsites of the current site using the REST api. Here is the code snippet:

//Subsites
        function searchSubSites(webUrl, success, failure) {
            var url = webUrl + "/_api/site/rootWeb/webinfos";
            $.ajax({
                url: url,
                cache: false,
                method: "GET",
                headers: { "Accept": "application/json; odata=verbose", "X-RequestDigest": jQuery("#__REQUESTDIGEST").val() },
                success: function (data) {
                    success(data);
                },
                error: function (data) {
                    failure(data);
                }
            });
        }

        searchSubSites(currentURL,
          function (data) {

              for (var i = 0; i < data.d.results.length; i++) {
                  $("#SSPanel").append(currentURL + "" + data.d.results[i].ServerRelativeUrl + "<br/>");
              }
          },
          function (error) {
              console.log(JSON.stringify(error));

          }
        );

In IE11 it executes without issue: enter image description here

However on Chrome/Firefox/Edge I get a 403 unauthorized error: enter image description here

Here are the permissions that I have given the app: enter image description here

Can anyone shed any light on this? I know SharePoint Add-Ins are particular about their permissions, but it doesn't make any sense why it would allow the REST call in IE and not the others.

5

Appweb and Hostweb are two different origins, so something has to allow your AppWeb to access the Hostweb. If your code would work any script could access your site.

Search for HostWeb AppWeb access on Google.

Your IE most likely works because it was already authenticated on the Site.. try it with InPrivate browsing.

PS: odata=verbose gives you a lot of data you will never use, =nometadata or =minimalmetadata should be more than enough.

See JSON Light specs: https://blogs.office.com/2014/08/13/json-light-support-rest-sharepoint-api-released/

| improve this answer | |
  • Thanks Danny! Done a little more research and you're right, I didnt fully understand the context of which the REST calls were being made. Going to write up an answer now with the correct syntax. It was the fact that IE was allowing it that threw me off! You're a credit to SE. – Ray Hogan Apr 20 '16 at 10:43
  • +1 for the JSON Light – wjervis Apr 20 '16 at 15:51
1

Based on what Danny said to me, I looked a bit further into the context of which the REST calls are made. Using this as my resource my working code looks like so:

   var SPHostUrl = decodeURIComponent(getQueryStringParameter("SPHostUrl"));
   var SPAppWebUrl = decodeURIComponent(getQueryStringParameter("SPAppWebUrl"));    
    //Subsites
                function searchSubSites(webUrl, success, failure) {
                    var url = SPAppWebUrl + "/_api/SP.AppContextSite(@target)" + "/site/rootWeb/webinfos?" + "@target='" + webUrl + "'";
                    $.ajax({
                        url: url,
                        cache: false,
                        method: "GET",
                        headers: { "Accept": "application/json; odata=verbose" },
                        success: function (data) {
                            success(data);
                        },
                        error: function (data) {
                            failure(data); 
                        }
                    });
                }

                searchSubSites(SPHostUrl,
                  function (data) {

                      for (var i = 0; i < data.d.results.length; i++) {
                          $("#SSPanel").append(SPHostUrl + "" + data.d.results[i].ServerRelativeUrl + "<br/>");
                      }
                  },
                  function (error) {
                      console.log(JSON.stringify(error));

                  }
                );

I originally had the code running directly on a SharePoint page via the content editor webpart. It worked fine. I then moved it into an app so that I could use it as an app part. This is when I ran into the 403 errors. This was due to sharepoint apps having their own domain, so when I was trying to directly call the API from the host web it was 'forbidden' since it's origin is from another domain. To get around this, call the endpoint from the app web but include context of the host web in the URL.

| improve this answer | |
0

Can you check any differences in the headers sent to SharePoint? Maybe not exactly the same, but I had an issue with the Postman rest app in Chrome adding an origin header to the rest call that was not accepted.

Another issue I had was having a CORS chrome plugin giving trouble. But this would not explain it not working in Edge.

--edit I've had a closer look at the code, but is there any reason why you would send the X-RequestDigest header with a GET request? As far as I know this is only need when doing post request. Source: http://www.wictorwilen.se/sharepoint-2013-how-to-refresh-the-request-digest-value-in-javascript

| improve this answer | |
  • I have no extensions running in Chrome. I tried it from home and from work with the same results. I asked other colleagues to try and they see the same -- working in IE, 403 everywhere else. – Ray Hogan Apr 20 '16 at 9:55
  • Regarding the X-RequestDigest... I put that in just to see if it would make any difference. It doesn't work with or without it. – Ray Hogan Apr 20 '16 at 10:05
  • Is this a SharePoint hosted add-in or a provider hosted add-in? – Oak3 Apr 20 '16 at 10:17
  • "useless" Headers can almost never be an issue. Think of a GET request as a postcard, and a POST request as an Envelope with a Letter inside. Unless the server checks and does something with it you can write (Headers) anything you want on the postcard/envelope.. – Danny '365CSI' Engelman Apr 20 '16 at 13:41
  • Unless it's an origin header which gave me a small headache as I wasn't aware it was attached to the get request using Postman. And that gives a 403 as well. – Oak3 Apr 20 '16 at 19:01

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.