Forum Discussion

MarksPoint's avatar
MarksPoint
Copper Contributor
Oct 21, 2020

Sudden CORS errors fetching https://rdweb.wvd.microsoft.com/api/feeddiscovery/webfeeddiscovery.aspx

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:

https://srdn.io/2020/05/retrieving-rdp-files-to-leverage-the-new-remote-desktop-client-for-connecting-to-windows-virtual-desktop-resources/

 

The first thing we do, from a client's perspective, is fetch the webfeeddiscovery xml from https://rdweb.wvd.microsoft.com/api/feeddiscovery/webfeeddiscovery.aspx. 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: 

https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery) we get the following message in Chrome:
 
Access to fetch at 'https://rdweb.wvd.microsoft.com/api/feeddiscovery/webfeeddiscovery.aspx' from origin 'https://[our-tenant].sharepoint.com' 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].sharepoint.com. 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?
 
Mark
  • MarksPoint's avatar
    MarksPoint
    Copper Contributor
    Oct 21, 2020

    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': 'com.microsoft.rdc.html/1.0.21.9'
     
    ... and the result is a working web part (or widget, to be more precise)!
     

     

    • MarksPoint's avatar
      MarksPoint
      Copper Contributor
      Nov 04, 2020

      MarksPoint 

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

       

      Same CORS errors, even with the custom header added.

       

      I checked the headers in the regular webclient (at https://rdweb.wvd.microsoft.com/arm/webclient/index.html) and noticed they updated the X-MS-User-Agent header to include a different (newer?) version: 

      'X-MS-User-Agent': 'com.microsoft.rdc.html/1.0.21.16'
      instead of
      'X-MS-User-Agent': 'com.microsoft.rdc.html/1.0.21.9'
       
      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?
       
      Mark

Resources