none
XMLHttpRequest.open() fails in office app, but works in IE RRS feed

  • Question

  • I am having a strange issue. I keep getting access denied on opening an XMLHttpRequest WITHIN my task pane app running in VS 2013.

    CORS IS enabled on the remote server. I can run the same javascript in a plain html page in IE 10, and it WORKS.

    Note: it took me a while to get it to work, turns out I had to add the remote domain to my trusted sites in the local intranet zone. Firefox and Chrome worked fine without that.

    What does the embedded IFrame do differently from plain IE?
     Here's the code:

          var xhr = new XMLHttpRequest();
    
            if ("withCredentials" in xhr) {
    
                xhr.onerror = function (error) {
                    app.showNotification('Error!' + error.statusText);
                };
    
                xhr.onload = function () {
                    $('#login-result').val(JSON.parse(this.responseText)["ticket"]);
                }
                app.showNotification($('#login-url').val());
                xhr.open("POST", $('#login-url').val(), true);
                xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
                xhr.send('username=' + $('#login-name').val() + '&password=' + $('#login-password').val());
    
            } else {
                app.showNotification('BAH!');
            }   

    and yes, I tried jquery too. The result is the same - access denied

     $.ajax({
                url: $('#login-url').val(),
                type: 'POST',
                crossDomain: true,        
                dataType: 'json',
                data: 'username=' + $('#login-name').val() + '&password=' + $('#login-password').val(), // or $('#myform').serializeArray()           
            }).done(function (data) {
                $('#login-result').val(data.ticket);
                app.showNotification("Got ticket", data.ticket);
            })
                .error(function (error) {
                    app.showNotification('Error!', error.statusText);
                });

    it must be some kind of a stupid security thing. But why does it work in an html page outside office apps?

    Anyone?

    P.S. The html page is deployed in IIS on domain A, the login-url points to domain B. So the fact that VS debugger uses another IIS with a different port is no different, it's just domain C talking to domain B.
    • Edited by Maria_OT Monday, December 23, 2013 8:53 PM
    Monday, December 23, 2013 8:48 PM

Answers

  • Hi Maria,

    According to Privacy and security for apps for Office:

    Because apps for Office are webpages that run in a web browser control, they have to observe the same-origin policy: a webpage in one domain cannot make XmlHttpRequest web service calls to another domain other than the one where it is hosted.

    True, unless the second domain supports CORS, which it does.

    I found out what the difference between running in an html page in IE and in office app was - the office app running in VS 1013 was using IIS Express with https enabled. When forcing it to run on the default IIS without https, cross domain requests WERE sent out, as expected.

    So http to http works, and https to http doesn't, as one would expect.



    • Edited by Maria_OT Thursday, January 9, 2014 8:20 PM
    • Marked as answer by Maria_OT Thursday, January 9, 2014 8:20 PM
    Thursday, January 2, 2014 2:41 PM

All replies

  • Hi Maria,

    According to Privacy and security for apps for Office:

    Because apps for Office are webpages that run in a web browser control, they have to observe the same-origin policy: a webpage in one domain cannot make XmlHttpRequest web service calls to another domain other than the one where it is hosted.

    One way to overcome this limitation is to use JSON/P—provide a proxy for the web service by including a script tag with a src attribute that points to some script hosted on any domain. The developer can programmatically create the script tags, dynamically creating the URL to which to point the src attribute, and passing parameters to the URL via URI query parameters. Web service providers create and host JavaScript code at specific URLs, and return different scripts depending on the URI query parameters. These scripts then execute where they are inserted and work as expected.

    Hope this can give you help.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • Marked as answer by George HuaModerator Tuesday, December 31, 2013 5:31 AM
    • Unmarked as answer by Maria_OT Thursday, January 2, 2014 2:41 PM
    Thursday, December 26, 2013 10:15 AM
    Moderator
  • Hi Maria,

    According to Privacy and security for apps for Office:

    Because apps for Office are webpages that run in a web browser control, they have to observe the same-origin policy: a webpage in one domain cannot make XmlHttpRequest web service calls to another domain other than the one where it is hosted.

    True, unless the second domain supports CORS, which it does.

    I found out what the difference between running in an html page in IE and in office app was - the office app running in VS 1013 was using IIS Express with https enabled. When forcing it to run on the default IIS without https, cross domain requests WERE sent out, as expected.

    So http to http works, and https to http doesn't, as one would expect.



    • Edited by Maria_OT Thursday, January 9, 2014 8:20 PM
    • Marked as answer by Maria_OT Thursday, January 9, 2014 8:20 PM
    Thursday, January 2, 2014 2:41 PM