Sudden CORS errors fetching've%20built%20a%20solution%20(web%20part)%20that%20allows%20users%20t'''''%20from%20origin%20''%20has%20been%20blocked%20by%20CORS%20policy%3A%20No%20'Access-Control-Allow-Origin'%20header%20is%20present%20on%20the%20requested%20resource.%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3EChecking%20the%20Network%20tab%20I%20can%20confirm%20that%20the%20response%20headers%20of%20my%20GET%20request%20indeed%20don't%20contain%20the%20necessary%20headers%20like%20'%3CSPAN%3EAccess-Control-Allow-Origin''s%20also%20being%20fired%20to%20this%20url%2C%26nbsp%3B%3CU%3Edoes%3C%2FU%3E%20contain%20these%20response%20headers.%26nbsp%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3EIs%20this%20something%20that%20was%20changed%20on%20Microsoft's%20end%20recently%3F%3C%2FDIV%3E%3CDIV%3ECould%20it%20be%20restored%20to%20its%20original%20configuration%20or%20are%20there%20alternatives%20to%20what%20we're%20trying%20to%20accompli'X-MS-User-Agent'%3C%2FSPAN%3E%3CSPAN%3E%3A%20%3C%2FSPAN%3E%3CSPAN%3E''%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E...%20and%20the%20result%20is%20a%20working%20web%20part%20(or%20widget%2C%20to%20be%20more%20precise)!%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%26nb
New Contributor

We've built a solution (web part) that allows users to launch Windows Virtual Desktop apps and desktops from within SharePoint. For this, we used some of the ideas that were described in following article:


The first thing we do, from a client's perspective, is fetch the webfeeddiscovery xml from We parse the xml and try to read the Tenant Feed Url and then we continue with some other requests to show all apps and desktops in the web part.


Up until recently this worked fine and we were able to show the user a list of apps and desktops which he/she has access to and could then open these using a downloaded RDP file.

Unfortunately we're not longer able to use this endpoint because of CORS headers not being present in the response.

When we do a fetch to that webfeeddiscovery.aspx url (or a different url we've had some success with in the past: we get the following message in Chrome:
Access to fetch at '' from origin 'https://[our-tenant]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Checking the Network tab I can confirm that the response headers of my GET request indeed don't contain the necessary headers like 'Access-Control-Allow-Origin': https://[our-tenant] However, the OPTIONS request that's also being fired to this url, does contain these response headers. 
Is this something that was changed on Microsoft's end recently?
Could it be restored to its original configuration or are there alternatives to what we're trying to accomplish?
3 Replies

With the help of a colleague I was able to fix the issue myself. Apparently something changed on the service end that now requires an extra header:




With the addition of this header the request is now again successful:

'X-MS-User-Agent': ''
... and the result is a working web part (or widget, to be more precise)!



aaaaand it's broken again... :cry:


Same CORS errors, even with the custom header added.


I checked the headers in the regular webclient (at and noticed they updated the X-MS-User-Agent header to include a different (newer?) version: 

'X-MS-User-Agent': ''
instead of
I updated the header in my code but this didn't fix it.
Please help! This doesn't seem to be the right way to integrate with WVD. But what is, then?