Question about CORS and Redirects for Widevine License Requests

[vzTrevorHunsaker]

Due to a quirk of our backend, we sometimes have to re-direct Widevine license requests to a different server. I have attempted to do this by returning a 307 response with the proper Location header. Looks like CORS issues may be preventing this solution from working, (we use values from the cookie to do some processing before sending on the request to Widevine's servers). It looks like I may have to come to terms with the fact that a redirect-based solution will not work in this case, but before I do that I'm seeing something odd in the network pane of Chrome's dev tools that leads me to believe that we're successfully delivering a license to the browser, which makes me wonder why playback doesn't happen.

I have exported the networking tab's output as an .har file

You can see that the original requests to my Widevine endpoint go to content.uplynk.localhost/wv, and have been 307 redirected to content-dev.uplynk.localhost/wv. You can also see subsequent requests to the redirected domain successfully return a license with a 200 response.

However, there are a couple of requests that the browser apparently blocks because of CORS. A
screenshot from the network panel

In there, you can again see the initial requests, the redirected requests, as well as some requests that failed. The number of failed requests correspond with the number of CORS-related errors I find in my JS console:

Failed to load http://content-dev.uplynk.localhost:8000/wv: The 'Access-Control-Allow-Origin' header has a value 'http://localhost:8001' that is not equal to the supplied origin. Origin 'null' is therefore not allowed access. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Given that it appears as though we're successfully delivering a license via redirects, I'm hoping there's just some CORS-related magic I can work to convince the browser to actually accept and use them. Or am I just up in the night?

[chrisfillmore]

You can circumvent CORS security a variety of ways for the purposes of testing:

• Disable same-origin policy (for Chrome: https://stackoverflow.com/a/6083677)
• Access-Control-Allow-Origin: * extension for Chrome
• Rewrite response headers via Charles Proxy, Fiddler, etc

This would at least tell you if you had a CORS issue.

[TheModMaker]

Since the license server is on a different origin (server) than the Shaka demo, you'll need to add CORS headers so the browser will allow the request. You can read more about CORS here.

Also note that the demo now uses a service worker for requests, which have different requirements for CORS settings. I have seen that even with --disable-web-security the request may fail because the service worker still requires CORS. In Chrome, you can go to the DevTools and in the "Application" tab select the "Service Worker" on the left and check the "Bypass for network" checkbox to see if this is CORS related.

Lastly, some browsers don't support cross-origin redirects. See #666 for more details about this.

[vzTrevorHunsaker]

We do insert CORS headers in our responses and they worked swimmingly up until we found a case where we needed to send a re-direct. It appears as though it's CORS + redirects specifically that's catching us out here.

I will try both of these suggestions to attempt to validate. Thanks!

[vzTrevorHunsaker]

So, I am able to successfully play this stream when I --disable-web-security and check the service workers' "Bypass for network" box. Which leads me to believe this is a CORS issue, but I also am under the impression that it's a CORS issue I shouldn't be seeing, given the headers that I'm returning in my responses.

I mean, the re-directed requests actually succeed, and deliver Widevine licenses. My question is, given that's the case, why is the browser refusing to use them? Browser bug? I'm misunderstanding something?

[joeyparrish]

I think it may be a browser bug. I am surprised that the browser treats CORS differently in a service worker. My best suggestion is to file a bug on http://crbug.com/ and link to it here so we can follow along.

[vzTrevorHunsaker]

Ok, I've filed a report against Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=807706

[joeyparrish]

I believe we can fix our demo's service worker to avoid this browser behavior. I hope to have an update out soon.