none
Sharepoint Hosted App Gives "There is no trusted URLs configured for the app deployment" error RRS feed

  • Question

  • I am trying to deploy a sharepoint hosted app onto SharePoint Online that uses the cross-domain library to get data out of the host web.  There is nothing in it that is provider hosted so I am completely confused as to why I am getting this error.  Has anyone else seen this?

    function getData() {
        //Get the URI decoded URLs. 
        hostweburl =
            decodeURIComponent(
                getQueryStringParameter("SPHostUrl")
        );
        appweburl =
            decodeURIComponent(
                getQueryStringParameter("SPAppWebUrl")
        );
    
        // resources are in URLs in the form: 
        // web_url/_layouts/15/resource 
        var scriptbase = hostweburl + "/_layouts/15/";
    
        // Load the js files and continue to the successHandler 
        $.getScript(scriptbase + "SP.RequestExecutor.js", execCrossDomainRequest);
    }
    
    // Function to prepare and issue the request to get 
    //  SharePoint data 
    function execCrossDomainRequest() {
        // executor: The RequestExecutor object 
        // Initialize the RequestExecutor with the app web URL. 
        var executor = new SP.RequestExecutor(appweburl);
    
        // Issue the call against the app web. 
        // To get the title using REST we can hit the endpoint: 
        //      appweburl/_api/web/lists/getbytitle('listname')/items 
        // The response formats the data in the JSON format. 
        // The functions successHandler and errorHandler attend the 
        //      sucess and error events respectively. 
        executor.executeAsync(
            {
                url:
                    appweburl +
                    "/_api/Data/$metadata",
                method: "GET",
                success: successHandler,
                error: errorHandler
            }
        );
    }

    Friday, February 21, 2014 6:49 AM

All replies

  • Hi Michael,

    Have you tried this solution?

    http://social.msdn.microsoft.com/Forums/sharepoint/en-US/ce944e8a-7cd4-4396-bc39-b76bae8504a7/sharepoint-2013-rest-to-list-in-app-returns-the-error-there-is-no-trusted-urls-configured-for-the?forum=appsforsharepoint



    srj

    Friday, February 21, 2014 6:52 PM
  • Yes that solution is meant for provider hosted apps.  If you try and setup the app principle like that in a sharepoint hosted app you get "Your domain doesn't match the expected domain for this app deployment" as an error which makes sense because you don't have anything set as a domain in the deployment (since it is being generated on the fly).

    The strange thing is that this worked for several days with no error.

    Friday, February 21, 2014 7:54 PM
  • Have you got any other solution? for this issue

    srj

    Saturday, February 22, 2014 6:57 AM
  • Hi,

    I've your same problem, on-premise my app run without error but when I install on SharePoint Online I've your error.

    I've also tested with simple code like this:

    'use strict';
    
    $(document).ready(function () {
        getListTitle();
    });
    
    var factory = null;
    var appContextSite = null;
    var clientContextHost = null;
    var hostWeb = null;
    var hostWebUrl = '';
    var appWebUrl = '';
    
    function getListTitle() {
        hostWebUrl = decodeURIComponent(getQueryStringParameter('SPHostUrl'));
        appWebUrl = decodeURIComponent(getQueryStringParameter('SPAppWebUrl'));
    
        clientContextHost = new SP.ClientContext(appWebUrl);
        factory = new SP.ProxyWebRequestExecutorFactory(appWebUrl);
        clientContextHost.set_webRequestExecutorFactory(factory);
        appContextSite = new SP.AppContextSite(clientContextHost, hostWebUrl);
    
        hostWeb = appContextSite.get_web();
    
        var list = hostWeb.get_lists().getByTitle('Documents');
    
        clientContextHost.load(list);
        
        clientContextHost.executeQueryAsync(
            function () {
                alert(list.get_title());
            },
            function (sender, args) {
                alert(args.get_message());
            }
        );
    }
    
    function getQueryStringParameter (paramToRetrieve) {
        var params = document.URL.split("?").length > 1 ?
            document.URL.split("?")[1].split("&") : [];
    
        for (var i = 0; i < params.length; i = i + 1) {
            var singleParam = params[i].split("=");
            if (singleParam[0] == paramToRetrieve)
                return singleParam[1];
        }
    
        return '';
    }

    Without success...

    Have you find a solution for the issue?

    Tuesday, February 25, 2014 4:36 PM
  • Hi,

    since last day i am getting the exact same error message. "There is no trusted URLs configured for the app deployment" (or the German Message "Für die App-Bereitstellung sind keine vertrauenswürdigen URLs konfiguriert")

    I used the code fragments for months and now i am getting the error when using the RequestExecutor for getting the SPHost Data.

    function getSPHostTitle() {
    
    	var context = new SP.ClientContext(appWebUrl);
    	var factory = new SP.ProxyWebRequestExecutorFactory(appWebUrl);
    	context.set_webRequestExecutorFactory(factory);
    
    	var appContextSite = new SP.AppContextSite(context, hostWebUrl);
    
    	var rootWeb = appContextSite.get_web();
    	context.load(rootWeb);
    
    	context.executeQueryAsync(
    		function (result) {
    			$('#message').append("<div>HostTitle: " + rootWeb.get_title() + "</div>");
    		},
    		function (s, args) {
    			$('#message').append("<div>Error: " + args.get_message() + "</div>");
    		});
    }

    I am developing SharePoint hosted apps on SharePoint Online.

    Does anybody know if Microsoft changed something in the SP Online backend?

    Wednesday, February 26, 2014 1:08 PM
  • Hi,

    I have read this thread and I've tested my app with another subscription and it's run without error.

    I think really that is a subscription issue.

     
    Wednesday, February 26, 2014 3:12 PM
  • Can you check and confirm your build versions numbers?
    (via https://<your domin>.sharepoint.com/_vti_pvt/buildversion.cnf)

    x2 Tenancies reporting different build numbers -

    Problem Tenant:
    vti_buildversion:SR|16.0.2607.1205

    Working Tenant:
    vti_buildversion:SR|16.0.2607.1208


    Wednesday, February 26, 2014 4:47 PM
  • We've been encountering the same issue this week with our O365-hosted SharePoint Extranet. FWIW, I've opened a service request on the issue. I'll post back if I get anything meaningful out of that effort.

    @Obilogic, we are seeing the issue on build SR|16.0.2607.1208.

    Wednesday, February 26, 2014 8:02 PM
  • We have following tenant versions:

    Problem Tenant:
    vti_buildversion:SR|16.0.2607.1208

    Working Tenant:
    vti_buildversion:SR|16.0.2621.1204

    Thursday, February 27, 2014 8:50 AM
  • Thanks andrea,

    So it seems similar issue may happen in future also, So I had changed my codes to use "$.ajax" instead "executor.executeAsync". And its working fine.


    srj

    Thursday, February 27, 2014 12:08 PM
  • We have the tenant version:

    vti_encoding:SR|utf8-nl

    vti_buildversion:SR|16.0.2607.1205

    Not Working...

    It was working for several days suddenly it stopped working and throwing error "There is no trusted URLs configured for the app deployment."

    I found a solution for the above error from a link:

    In the above link they are asking to add a tag in the AppManifest.xml file. Like below

    <AppPrincipal> <Internal AllowedRemoteHostUrl="~remoteAppUrl"/> </AppPrincipal>

    but after adding the above mentioned tag in AppManifest.xml we are getting the another error "Your domain doesn't match the expected domain for this app deployment".

    It would be greatly appreciated if any one can help us

    opusbabu@gmail.com

    91 93813 55666



    Satheesh Babu, opusbabu@gmail.com OptimusBT Pvt. Ltd., Bangalore.

    Friday, February 28, 2014 10:02 AM
  • Hi All,

    After some further investigation I believe I may have identified a potential issue and a possible workaround...


    The following code appears to work (on affected and unaffected tenants) ...

    var hostweburl;
    var appweburl;
    
    // Load the required SharePoint libraries
    $(document).ready(function () {
      //Get the URI decoded URLs.
      hostweburl = decodeURIComponent(getQueryStringParameter("SPHostUrl"));
      appweburl = decodeURIComponent(getQueryStringParameter("SPAppWebUrl"));
      // Load the js file and continue to the 
      //   success event handler
      $.getScript("/_layouts/15/SP.RequestExecutor.js", execCrossDomainRequest);
    });
    
    // Function to prepare and issue the request to get
    //  SharePoint data
    function execCrossDomainRequest() {
      var executor;
    
      // Initialize the RequestExecutor with the app web URL.
      executor = new SP.RequestExecutor("/");
    
    
      // Issue the call against the host web.
      // To get the title using REST we can hit the endpoint:
      //   app_web_url/_api/SP.AppContextSite(@target)/web/title?@target='siteUrl'
      // The response formats the data in the JSON format.
      // The functions successHandler and errorHandler attend the
        //      success and error events respectively.
      alert(appweburl + "/_api/SP.AppContextSite(@target)/web/title?@target='" + hostweburl + "'");
      executor.executeAsync(
          {
            url: appweburl +"/_api/SP.AppContextSite(@target)/web/title?@target='" + hostweburl + "'",
            method: "GET",
            headers: { "Accept": "application/json; odata=verbose" },
            success: successHandler,
            error: errorHandler
          }
      );
    }
    
    // Function to handle the success event.
    // Prints the host web's title to the page.
    function successHandler(data) {
      var jsonObject = JSON.parse(data.body);
    
      document.getElementById("HostwebTitle").innerHTML =
          "<b>" + jsonObject.d.Title + "</b>";
    }
    
    // Function to handle the error event.
    // Prints the error message to the page.
    function errorHandler(data, errorCode, errorMessage) {
      document.getElementById("HostwebTitle").innerText =
          "Could not complete cross-domain call: " + errorMessage;
    }
    
    // Function to retrieve a query string value.
    // For production purposes you may want to use
    //  a library to handle the query string.
    function getQueryStringParameter(paramToRetrieve) {
      var params =
          document.URL.split("?")[1].split("&");
      var strParams = "";
      for (var i = 0; i < params.length; i = i + 1) {
        var singleParam = params[i].split("=");
        if (singleParam[0] == paramToRetrieve)
          return singleParam[1];
      }
    }



    Whilst the following code appears to throw the "There is no trusted URLs configured for the app deployment" error (on affected tenants)...

    var hostweburl;
    var appweburl;
    
    // Load the required SharePoint libraries
    $(document).ready(function () {
      //Get the URI decoded URLs.
      hostweburl = decodeURIComponent(getQueryStringParameter("SPHostUrl"));
      appweburl = decodeURIComponent(getQueryStringParameter("SPAppWebUrl"));
      // Load the js file and continue to the 
      //   success event handler
      $.getScript("/_layouts/15/SP.RequestExecutor.js", execCrossDomainRequest);
    });
    
    // Function to prepare and issue the request to get
    //  SharePoint data
    function execCrossDomainRequest() {
      var executor;
    
      // Initialize the RequestExecutor with the app web URL.
      executor = new SP.RequestExecutor(appweburl);
    
      // Issue the call against the host web.
      // To get the title using REST we can hit the endpoint:
      //   app_web_url/_api/SP.AppContextSite(@target)/web/title?@target='siteUrl'
      // The response formats the data in the JSON format.
      // The functions successHandler and errorHandler attend the
        //      success and error events respectively.
      alert(appweburl + "/_api/SP.AppContextSite(@target)/web/title?@target='" + hostweburl + "'");
      executor.executeAsync(
          {
            url: appweburl +"/_api/SP.AppContextSite(@target)/web/title?@target='" + hostweburl + "'",
            method: "GET",
            headers: { "Accept": "application/json; odata=verbose" },
            success: successHandler,
            error: errorHandler
          }
      );
    }
    
    // Function to handle the success event.
    // Prints the host web's title to the page.
    function successHandler(data) {
      var jsonObject = JSON.parse(data.body);
    
      document.getElementById("HostwebTitle").innerHTML =
          "<b>" + jsonObject.d.Title + "</b>";
    }
    
    // Function to handle the error event.
    // Prints the error message to the page.
    function errorHandler(data, errorCode, errorMessage) {
      document.getElementById("HostwebTitle").innerText =
          "Could not complete cross-domain call: " + errorMessage;
    }
    
    // Function to retrieve a query string value.
    // For production purposes you may want to use
    //  a library to handle the query string.
    function getQueryStringParameter(paramToRetrieve) {
      var params =
          document.URL.split("?")[1].split("&");
      var strParams = "";
      for (var i = 0; i < params.length; i = i + 1) {
        var singleParam = params[i].split("=");
        if (singleParam[0] == paramToRetrieve)
          return singleParam[1];
      }
    }


    The only difference being the " executor = new SP.RequestExecutor();" call in the 'execCrossDomainRequest()' function...


    In the working version this is called using:

    // Initialize the RequestExecutor with the app web URL.
    executor = new SP.RequestExecutor("/");
    


    Whilst in the broken / problem version it is called using:

    // Initialize the RequestExecutor with the app web URL.
    executor = new SP.RequestExecutor(appweburl);

    Where 'appweburl' param equals:

    var appweburl = decodeURIComponent(getQueryStringParameter("SPAppWebUrl"));

    So..

    Although making the "new SP.RequestExecutor()" call with the 'full AppWebUrl' was working previously.. it appears to be now be failing (on affected tenancies) whilst making the "new SP.RequestExecutor()" call with "/" appears to still be working..

    Can anyone with access to source please test and confirm / deny if this gives the same outcome?

    Thanks



    • Proposed as answer by Obilogic Friday, February 28, 2014 12:19 PM
    Friday, February 28, 2014 12:17 PM
  • @Obilogic, Sean w/ ThreeWill here again. As I mentioned on SPYam, your SP.RequestExecutor("/") fix appears to be working for us in my preliminary testing. Not sure if it's the final answer, but it's WAY better than being down.
    Friday, February 28, 2014 6:10 PM
  • Good to hear is working for you as well Sean.

    Definitely regarding as a 'workaround' (not a fix).. especially until get clarification/confirmation on which approach is regarded as correct / best practice.

    Friday, February 28, 2014 7:21 PM
  • Update on this issue from our end:

    1. We have not been able to get the "/" hack working for writes/POSTs (I'm trying a couple of things to resolve this now).
    2. At some point Friday the "/" fix stopped working for reads/GETs, but it has resumed working now. The disruption may have been caused by Microsoft's troubleshooting efforts for all I know (an admittedly optimistic interpretation).
    3. We have not had further contact from Microsoft since late Thursday night. I'll give them a call for an update soon.

    We'll keep the thread posted as we learn more. If anyone else has other information/questions/suggestions, let us know.

    Monday, March 3, 2014 3:27 PM
  • any body knows solution for this threads still am facing same problem.

    my site build version is

    vti_buildversion:SR|16.0.2607.1208

    from past 10 days am receiving "There is no trusted URLs configured for the app deployment"

    same code working fine before.Please guide.

    • Edited by Yateesha Tuesday, March 4, 2014 11:40 AM
    Tuesday, March 4, 2014 11:37 AM
  • I am also having the same problem... 

    Same code was working till 25th Feb, 2014 (evening around 5.00 pm) and stopped working from that time onwards... Still we are facing the same issue. "There is no trusted URLs configured for the app deployment"

    Thanks in advance and waiting for someone to come up with a fix/resolution for this issue.

    Thanks,

    Satheesh.

    9381355666 : opusbabu@gmail.com



    Satheesh Babu, opusbabu@gmail.com OptimusBT Pvt. Ltd., Bangalore.

    Wednesday, March 5, 2014 12:30 PM
  • Our Service Request officially made it past basic O365 Support to SharePoint Developer Support yesterday, but I have not heard any news from them since they took ownership of the issue. I'm still planning to keep this thread updated as soon as I have any news.

    @Satheesh, @Yateesh, if you only need REST access for data reads, it seems like *most* people are having success with @Obilogic's hack he mentions above. Instead of this:

    exec = SP.RequestExecutor(appWebUrl)

    Try this:

    exec = SP.RequestExecutor("/")

    This is only working for GETs when it does work. I don't believe anyone has a solution for POSTs yet.

    Good luck.

    Wednesday, March 5, 2014 5:11 PM
  • Possible solution alert: I just received word from our SharePoint Developer Support engineer. He's suggesting you remove all capital letters from your AppWebUrl argument to the SP.RequestExecutor. So something like this:

    exec = new SP.RequestExecutor(appWebUrl.toLowerCase());

    Might work for you. Right now this *is working* in all the cases I've tested in our sites, for both GETs and POSTs.

    If this *is* the cause, it would also explain the inconsistency in the error. Anyone who happened to already be normalizing the case of their AppWebUrl for whatever reason would not be affected by this.

    Please test ASAP and let the thread know if this works.

    • Proposed as answer by Obilogic Wednesday, March 5, 2014 10:17 PM
    Wednesday, March 5, 2014 8:09 PM
  • Thanks Sean. Suggested..

    exec = new SP.RequestExecutor(appWebUrl.toLowerCase());

    ..fix/workaround appears to be working in my initial testing for both GETs and POSTs (aka read and writes)

    (Can't say I've been ever normalizing the case of my AppWebUrl params in the past, will be interesting to see what the 'final response/resoluton' turns out to be)

    Wednesday, March 5, 2014 10:01 PM
  • Thanks Sean...

    appweburl.toLowerCase() working fine for me thanks lot.

    Thursday, March 6, 2014 6:53 AM
  • That did the trick on my end, thanks.

    Colorless Green Ideas Sleep Furiously http://www.sharepointnerd.com

    Saturday, April 5, 2014 12:24 PM