Pnpjs: Can sprestaddin be used to make any cross domain call, not just a host web?

[politicsruinseverything]

Thank you for reporting an issue, suggesting an enhancement, or asking a question. We appreciate your feedback - to help the team understand your
needs please complete the below template to ensure we have the details to help. Thanks!

Please check out the Docs to see if your question is already addressed there. This will help us ensure our documentation covers the most frequent questions.

Category

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

Version

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

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

If you are not using the latest release, please update and see if the issue is resolved before submitting an issue.

Expected / Desired Behavior / Question

Plain old SharePoint libraries have the SPWebProxy, SPWebRequestInfo, and SPWebResponseInfo classes that allow making cross-domain calls via the SharePoint server. Does the sp-addinhelpers/sprestaddin accomplish the same thing? I see in the example code that the variables indicate providing the host url and the add-in url. I have an Angular application that is not published to the farm as an add-in but rather a plain aspx page that hosts my Angular app. I'd like to utilize the web proxy to call into a different domain to fetch some data.

I searched the issues list for sprestaddin but did not find any issues containing this string.

Observed Behavior

Steps to Reproduce

[patrick-rodgers]

No, those classes are designed to work only with add-ins, and haven't really been updated as add-in development isn't really a focus any more with SPFx introduction. We haven't done anything to mimic SPWebProxy and don't have plans to, though would certainly review a PR. Why not expose web services your client app can call that handles the specific proxy operations from your server or Azure functions (or one of the many other varieties of the same)?

[politicsruinseverything]

Thanks, Patrick. I figured as much. As to "why not expose web services...", this is a large Fortune 100 company where that sort of thing is easier said than done. The web services already exist in different domains but, obviously, CORS is the issue. Recreating a bunch of services to duplicate another bunch of services just to get them into the same origin is a bodge, to say the least. Again, large company and getting CORS policy changed on services I do not own is going to be tough or impossible. There's a very good reason the original SP team went to the trouble of creating SPWebProxy. It fills a crucial business need. It would be great if you could entertain a feature request. I suspect there will be a lot of folks that would benefit and I imagine the implementation is pretty simple. Thanks!

[koltyakov]

@politicsruinseverything how would /_api/SP.WebProxy.Invoke helps with proxying any request to custom endpoints while it only works for Add-Ins and only if an endpoint is registered as RemoteEndpoint in AppManifest.xml?

It's not about the library capabilities but the server infrastructure. With only the client-side, it's not feasible consuming a service if a service is not intended to be consumed.

For the On-Prem, the solution for this would be:

• following Add-Ins infrastructure requirements and registering remote endpoint in AppManifest.xml,
• creating a custom SharePoint web service which would reverse proxy to a solution's endpoints (and obviously trim requests base on web and user context, etc.),
• enabling CORS on an external web service,
• or lifting a reverse proxy with CORS enabled.

[politicsruinseverything]

I don't know. That's why I asked the question "Can sprestaddin be used to make any cross domain call, not just a host web?". The documentation page is not explicit.

How would I have an AppManifest if my code is not deployed as an App as I stated in my original question?

[politicsruinseverything]

Finally. I found information that explicitly states WebProxy and RequestExecutor classes are only functional in an app context. I never knew this as I do not work with add-ins regularly. They are not practical or allowed in my environment. I do not see this mentioned anywhere on MS documentation. There, it just says the class "Represents the data from the caller needed to make the outbound web request." I guess people are supposed to just infer that to mean "to the host web only".

I can see why there's nothing you'd be able to implement that wouldn't already be covered by something like JSONP. There'd be no point.

Thanks for the pleasant exchange of information as always.