Pnpjs: When using spOdataEntity object baseUrl config parameter is ignored

[bennyszantar]

I'm using sp-rest-proxy library to develop SPA apps for SP 2013. After using spOdataEntity in .get() returned object is using absolute url instead baseUrl from configuration.

Category

• [ ] Enhancement
• [X] Bug
• [ ] Question
• [ ] Documentation gap/issue

Version

Please specify what version of the library you are using: [ 1.3.7]

Please specify what version(s) of SharePoint you are targeting: [ 2013 ]

Expected / Desired Behavior / Question

After using .get(spODataEntity(Item)) returning object should be able to update,create etc. with baseUrl used in configuration.

Observed Behavior

Absolute url is used when proxying which throws 401 unauthorized error.

Standard update works fine

sp.setup({
  sp: {
    headers: {
      Accept: "application/json;odata=verbose"
    },
    baseUrl: " " // for localhost development
  }
});

sp.web.lists.getByTitle('list').items.getById(50)
    .update({
      Title: 'test'
 })

Using spODataEntity

sp.setup({
  sp: {
    headers: {
      Accept: "application/json;odata=verbose"
    },
    baseUrl: " "  // for localhost development
  }
});

interface Person {
  Id: number;
  Title: string;
}

const fetchPeople = async (listName: string): Promise<Item> => {
  return sp.web.lists
    .getByTitle(listName)
    .items.getById(1)
    .get(spODataEntity<Item, Person>(Item));
};

 fetchPeople("list").then(async person => {
       //it uses absolute server url instead baseUrl from configuration
        let test = await person.update({
          Title: 'TestowyUpdate'
        })
      });

Steps to Reproduce

Using spODataEntity

sp.setup({
  sp: {
    headers: {
      Accept: "application/json;odata=verbose"
    },
    baseUrl: " "  // for localhost development
  }
});

interface Person {
  Id: number;
  Title: string;
}

const fetchPeople = async (listName: string): Promise<Item> => {
  return sp.web.lists
    .getByTitle(listName)
    .items.getById(1)
    .get(spODataEntity<Item, Person>(Item));
};

 fetchPeople("list").then(async person => {
       //it uses absolute server url instead baseUrl from configuration
        let test = await person.update({
          Title: 'TestowyUpdate'
        })
      });

[patrick-rodgers]

Can you share one of the data entities that comes back (the json structure of an item)? The issue here is I think that we use the baseUrl from the configuration for the initial request and then we parse out the item urls from the result. A baseUrl that is a single space isn't a use case I have ever encountered before. My guess is that the information coming back in the object is not just a space - the situation where those urls aren't valid isn't one we have ever needed to handle, and am not sure how we would.

[bennyszantar]

Thank you for taking your time to respond to this issue.

Yes your quess about using baseUrl for initial request then taking item url from the result is the case here. Is it intended behaviour ? Why it is working without using entities then ?

Now about single space, it is used in local development for proxy (any call to localhost is then proxied to configured absolute url of sharepoint site). In any real project all my url's are set in .env files then injected in build process.

I would love to migrate my current solutions based on spscript (a small rest api wrapper library for SP) to pnp but this is a minor obstacle. I can live without spODataEntity but it looks like great feature :)

Thank you for your awesome work, pnp seems like great library :)

[patrick-rodgers]

Very happy to hear you like the library. Not sure of your configuration but you might try sp-rest-proxy. @koltyakov is a big contributor to this project and created that project to handle this very situation.

To answer your questions, yes this is the intended behavior - we count on the urls in the objects coming back to be correct. If they aren't we would need to handle that case in many places, not just the entity case.

In version 2 we are introducing extensions which make it a little easier to add custom functionality instead of using the entity model (though that still works too). Have a look at those and if you want try out the beta, we plan to release later this month (Dec 2019).

[koltyakov]

@fanatyko47, looks as something which we can tweak in sp-rest-proxy. Created a linked issue to take a looks and figure out.
In the proxy I try patching responses to bare minimum at the same time keeping behavior as close to what the API is as if is on a final SharePoint page. There also is an adhoc patching mechanism in proxy though PnPjs is the first class citizen so this is gonna be a fix.

[bennyszantar]

@patrick-rodgers thanks, i'll checkout beta for sure.
@koltyakov that sounds great, i'm using sp-rest-proxy on a daily basis, my dev life would be miserable without it, you're doing awesome work.

So it is possible to patch baseUrl into incoming data from sp in sp-rest-proxy as I understand correctly ? (patching all the uri's from results).

Let me know if you need any additional info or any help.

[koltyakov]

Hey @fanatyko47, published an update to sp-rest-proxy (v2.10.3), I already had odata.nextLink and odata.metadata URIs patching but not for OData verbose mode (hello 2013). Now it should also work for the verbose.

[bennyszantar]

@koltyakov it works like a charm, that was fast :)
Thank you all for resolving this issue so quickly.

[koltyakov]

Thanks for using the libraries, good feedback, and starts! Happy codding! Closing the issue.