POST request fails when calling the proxy (adding extra path to sharepoint request) about sp-rest-proxy HOT 5 CLOSED

Hi @yomer! I'm not getting why you're ever publishing sp-rest-proxy to IIS? It's not a good idea and misuse. The proxy is for local development, you always start the proxy together with local dev server on a Developer machine.

The proxy should also be bound to the root path or the same path as site. E.g. your SharePoint site is on https://contoso.sharepoint.com/sites/a-site, the same site is in private config, then in a local dev server let's say http://localhost:3000 the API is reachable at http://localhost:3000/ or http://localhost:3000/sites/a-site.

Could you please elaborate why publishing proxy instead of running it on each developer machine as it's designed? And even if publishing to some scoped devs working within a private local area network or server to server, why IIS?

from sp-rest-proxy.

Hi @koltyakov Thanks for answering.

I'm kind of in a middle of a transition. About five years ago, someone developed several angular apps which used SPServices jquery to connect to different Sharepoint document sites and show specific documentation to interested groups.

Just this year, the owner of these apps reached out to me because she had had them offline pretty much throughout all the pandemic. Doing cross domain calls directly from the apps to get the content from those SP sites was no longer an option since those require an OAuth token, so I'm using your proxy project to get these apps working while we come up with a better solution for the apps' owner.

These apps are only accessible from our private internal network. All of our internal apps are purely MS backend, so we use IIS to host them to all employees, there's no public access to our internal server and the connection count is relatively low to other public sites.

Just yesterday I got your proxy up and running on our internal IIS web server authenticating with a domain account. I wanted to use authentication with a clientid/secret Add-In App registered in our SP Online site collection, but it wouldn't work.

Given that this is a temporary solution while we most probably build modern SP sites to replace these apps, it's turning out fine.

I published the proxy on https://webserverUrl/sites/a-site and https://webserverUrl/a-site and both of them gave me some problems returning the proxied url as https://-----.sharepoint.com/a-site/a-site when hosting on https://webserverUrl/a-site, and https://-----.sharepoint.com/sites/a-site/sites/a-site when hosting on https://webserverUrl/sites/a-site

Because of the aforementioned url problems, I fiddled a bit with the Url.js file from your sp-rest-proxy project to remove the duplicated path via a simple .replace(). It was a dirty fast solution, but it worked out ok.

So that's the explanation and reasoning on using your project for these "production" apps. I don't know if I've dishonored😄 your project, but it's saving us some headaches from the person who owns these apps.

from sp-rest-proxy.

for these "production" apps. I don't know if I've dishonored😄 your project

Sure not. :) Thanks for using the lib! In the end of the day if you solve a problem, that more important. My part is to warn about a misuse just because of a risk of exposing some parts of your infra anonymously. Which is not the case starting locally with a dev server only listening localhost.

when hosting on https://webserverurl/a-site

This one is not OK. /a-site will be added to the path.

Usually, 90% of the dev use cases, when you start a local workbench. For a developer it's a local web server on http://localhost:3030 (port is different in different toolchains, in an Angular it might be 4242, but I'm not an Angular guy).

A developer is prompted for creds (site URL, strategy, creds wizard). A dev site is provided, let's stick with an abstract /sites/a-site. It's pretty common that an app/web part/spa works in a context of a single site where later on is deployed.

In a local workbench then all API requests just goes to relative paths. Assuming / converts to whatever configured in private.json. In our abstract sample is /sites/a-site. So /_api/web/ ends up to /sites/a-site/_api/web/ call.

However, sometimes some apps might empower more that a single site, but assume sub sites, parent sites, rollup scenarios. In these cases it might be reasonable to setup private.json to root and force an app with logic for sites paths.

Anyways, you adapt settings and base paths regarding a scenario.

from sp-rest-proxy.

Going to close the issue.

from sp-rest-proxy.

Yes, sorry I didn't reply earlier. I got caught up in work.

Thank you @koltyakov for the help, and for this great tool.

from sp-rest-proxy.