Fix PlayReady DRM in Edge browser

[mikrohard]

This PR fixes PlayReady DRM in Edge browser.

Why is this Pull Request needed?

On Edge, the raw license message is an UTF-16-encoded XML. It needs to be unpacked. The Challenge element is and base64 encoded xml string (the actual license challenge). Any HttpHeader elements need to be added to the xhr.

Same code can be found in shaka-player: https://github.com/shaka-project/shaka-player/blob/d6d5b155ff38428e96808094a341694d353ba289/lib/media/drm_engine.js#L1608

Are there any points in the code the reviewer needs to double check?

Code works and builds without warnings. I'm not primarily a JS developer. Check if everything is fine.

Resolves issues:

PlayReady playback not working in Edge browser.

Before:

After:

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[robwalch]

Related to #5667

[robwalch]

Shouldn't this be moved to the top of licenseXhrSetup so that the xhr is updated before licenseXhrSetup is called and final modification of the request object can be made by developers?

In shaka-player the message is unpacked before the network engine applies request filters.

[mikrohard]

Just unpacking the license request can easily be moved to the top. But this method also applies additional headers to the request, which requires the XHR to be in "open" state. Shaka uses their own request objects without this limitation.

Maybe we could extract the headers before and apply them afterwards. But this would (again) prevent the developers from modifying these specific headers.

Any suggestions?

[robwalch]

Maybe we could extract the headers before and apply them afterwards.

👍

There are several paths where XHR could be opened in setupLicenseXHR. It can also be opened in licenseXhrSetup:

hls.js/src/controller/eme-controller.ts

Lines 979 to 1030 in 0d3352d

	private setupLicenseXHR(
	xhr: XMLHttpRequest,
	url: string,
	keysListItem: MediaKeySessionContext,
	licenseChallenge: Uint8Array
	): Promise<{ xhr: XMLHttpRequest; licenseChallenge: Uint8Array }> {
	const licenseXhrSetup = this.config.licenseXhrSetup;
	if (!licenseXhrSetup) {
	xhr.open('POST', url, true);
	return Promise.resolve({ xhr, licenseChallenge });
	}
	return Promise.resolve()
	.then(() => {
	if (!keysListItem.decryptdata) {
	throw new Error('Key removed');
	}
	return licenseXhrSetup.call(
	this.hls,
	xhr,
	url,
	keysListItem,
	licenseChallenge
	);
	})
	.catch((error: Error) => {
	if (!keysListItem.decryptdata) {
	// Key session removed. Cancel license request.
	throw error;
	}
	// let's try to open before running setup
	xhr.open('POST', url, true);
	return licenseXhrSetup.call(
	this.hls,
	xhr,
	url,
	keysListItem,
	licenseChallenge
	);
	})
	.then((licenseXhrSetupResult) => {
	// if licenseXhrSetup did not yet call open, let's do it now
	if (!xhr.readyState) {
	xhr.open('POST', url, true);
	}
	const finalLicenseChallenge = licenseXhrSetupResult
	? licenseXhrSetupResult
	: licenseChallenge;
	return { xhr, licenseChallenge: finalLicenseChallenge };

Unpacking the license challenge first, before licenseXhrSetup is invoked , and then saving the headers until after XHR is opened for any of the paths above make sense if we insist on HLS.js applying these changes.

But this would (again) prevent the developers from modifying these specific headers.

Not necessarily. If licenseXhrSetup is implemented such that it throws when XHR is not opened, then licenseXhrSetup will be invoked again.

Otherwise, if licenseXhrSetup completes successfully on the first run then no, the headers would not be exposed to it - if this was an important path to cover, consider adding something like a headers argument to licenseXhrSetup.

So the question is, should the licenseChallenge argument in licenseXhrSetup always be the original keyMessage so that developers can unpack it themselves, or the unpacked version with headers?

Follow up question, why not both?

[mikrohard]

Well... by unpacking the licenseChallenge after licenseXhrSetup (like it is done now) the developers still get the original keyMessage and can do the unpacking on their own if the choose to do so. But for the majority of the users (who most likely only need to add some authentication headers required by their DRM provider) the unpacking is handled by hls.js before sending the request.

[robwalch]

by unpacking the licenseChallenge after licenseXhrSetup (like it is done now) the developers still get the original keyMessage and can do the unpacking on their own if the choose to do so

Fair enough. That keeps it simple and no change needed here.

Please address the other change requests

• https://github.com/video-dev/hls.js/pull/5699/files#r1277715485
• https://github.com/video-dev/hls.js/pull/5699/files#r1277719877

[mikrohard]

I've pushed the requested changes. Let me know if there is anything else that needs to be changed.