none
Sharepoint-hosted app ProjectData REST API calls getting 401 unauthorized error when site is accessed not on the server RRS feed

  • Question

  • I'm trying to query the PWA ProjectData endpoint for assignment information from a SharePoint-hosted app. The query is successful in testing. So, I've published and uploaded the app to SharePoint, and attempted to access it from my PWA instance. This works in Internet Explorer on the server running SharePoint and Project Server 2013, but not from any other computer or in Chrome. I am an administrator so should have full rights to the ProjectData endpoint.

    Here is my query:

    $.support.cors = true;
        $.ajax({
            url: spHostUrl + "/_api/ProjectData/Resources(guid'" + me.myId + "')/Assignments",
            dataType: "json",
            type: "GET",
            contentType: "application/json",
            data: "",
            beforeSend: function (xhr) {
                xhr.setRequestHeader("ACCEPT", "application/json; odata=verbose");
            },
            success: function (doc, text, xhr) {
                for (var x in doc.d.results) {
                    // Do stuff
                }
            },
            error: function (x, text, o) {
                $('#message').text(x + text + o);
            }
    
        });

    Here's what my request header gets turned into:

    OPTIONS http://server.com/pwa/_api/ProjectData/Resources(guid'c4b3a7c4-6cdc-e311-8c25-0022198e7bfe')/Assignments HTTP/1.1
    Accept: */*
    Origin: http://app-5b32c2bd5a6d8a.server.com
    Access-Control-Request-Method: GET
    Access-Control-Request-Headers: content-type, accept
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
    Host: msproject.itac-net.com
    Content-Length: 0
    DNT: 1
    Connection: Keep-Alive
    Pragma: no-cache
    

    And here's the response header:

    HTTP/1.1 401 Unauthorized
    Content-Type: text/plain; charset=utf-8
    Server: Microsoft-IIS/7.5
    SPRequestGuid: 51caa49c-e5d6-f0a9-0031-80c5340cd773
    request-id: 51caa49c-e5d6-f0a9-0031-80c5340cd773
    X-FRAME-OPTIONS: SAMEORIGIN
    SPRequestDuration: 4
    SPIisLatency: 1
    WWW-Authenticate: Negotiate
    WWW-Authenticate: NTLM
    X-Powered-By: ASP.NET
    MicrosoftSharePointTeamServices: 15.0.0.4420
    X-Content-Type-Options: nosniff
    X-MS-InvokeApp: 1; RequireReadOnly
    Access-Control-Allow-Origin: *
    Date: Tue, 15 Jul 2014 14:41:05 GMT
    Content-Length: 16
    Proxy-Support: Session-Based-Authentication
    
    401 UNAUTHORIZED


    I've tried scouring the internet, but cannot figure out what I am doing wrong. Do you think it's more likely a SharePoint or PWA setting issue than a programming issue?

    Please help! Thank you. 

    Tuesday, July 15, 2014 2:45 PM

All replies

  • Hello,

    If this works in the SharePoint app on the server, the same code / app should work on a client machine. It could be an infrastructure related issue. I assume from a client machine you can navigate to the ODATA endpoint in the browser and see the data returned to the client with the logged on user?

    Paul


    Paul Mather | Twitter | http://pwmather.wordpress.com | CPS

    Tuesday, July 15, 2014 3:11 PM
    Moderator
  • Hi Paul,

    Yes, I can navigate to the ODATA endpoint in the browser and see the data returned to the client.

    Do you have any ideas about where in the infrastructure things might be going wrong?

    Tuesday, July 15, 2014 3:17 PM
  • Hello,

    As it works in the browser, I cant see it being an infrastructure issue. Can you simplify the code and add it directly to the page in PWA using a content editor web part/ script editor web part and see if data is returned there (this removes the cross domain stuff from the app web).

    Paul


    Paul Mather | Twitter | http://pwmather.wordpress.com | CPS

    Wednesday, July 16, 2014 9:39 AM
    Moderator
  • That test worked. Although, I noticed it made a difference whether I was using http://servername/ or http://servername.domain.com/. The issue does seem to be related to the appweb being a different subdomain. Maybe I would be better off making a web part or just editing a new page with the script editor?

    Wednesday, July 16, 2014 12:52 PM
  • So in the app you are testing, are you using the FQDN or the NetBIOS name? Bad practice but could you test with both (hard code the absolute URL for testing purposes) then retest your app?

    If you are making a web part based on the new app model this will be an "app part" and probably have the same issues you are experiencing. If this is for something internal rather than a product you are developing to resell then the script editor / content editor web part approach could work for you.

    Paul


    Paul Mather | Twitter | http://pwmather.wordpress.com | CPS

    Wednesday, July 16, 2014 12:58 PM
    Moderator
  • The app I'm testing is getting the URL from the SPHostURL parameter, which seems to be giving me the FQDN. Tried the app hardcoding both the FQDN and the NetBIOS name and neither worked.
    • Edited by Sean Gibat Wednesday, July 16, 2014 1:38 PM
    Wednesday, July 16, 2014 1:30 PM
  • Hi,

    Have you found a solution to this issue? I'm facing the same problem and all of my data is exactly same as what you posted. I know this is due to cross domain request and that the 2nd domain is unable to authorize the request from first domain. I feel its something to do with the way how request is passed. I tried few options with CORS and JSONP, but neither worked for me. Please let me know.


    Thanks, Suneetha

    Thursday, December 10, 2015 10:19 PM
  • On your sharepoint app, did you ensure that your AppManifest.xml - Permissions tab has "Reporting (Project Server) as a "Read" permission? This is required if you are querying odata.
    Friday, December 11, 2015 4:34 PM