'How To Authenticate an AirPlay Session
I am serving HLS video with AWS CloudFront. The content is secured with Signed Cookies. I would like users to be able to use Apple AirPlay to watch the video on AirPlay devices. An authenticated iOS safari client with valid Cloud Front cookies is able to play the video.
If the user then uses AirPlay to watch the video on an AppleTV, the AppleTV gets the url to watch from the iPhone, but just the url, so when the request is made without the appropriate cookies header, the request is denied, as expected, with a 403.
I've looked for documentation and this is the only thing I can find (from 2012) which seems to indicate that something like this is possible, but to my read, seems to be lacking a critical bit of info on how to make it all work.
I have been able to determine that I can set cookies on the AirPlay device and that those cookies will be returned.
What I can't figure out is how to pass any kind of secret from the 'sharer' to the AirPlay device and how that could then get passed to the server. If I could get a cookie, a custom http header, or a query param appended to the request that AirPlay device makes, I could then use an AWS CloudFront Lambda to authenticate with the secret and set the cookies on the AirPlay device.
Solution 1:[1]
I had the same issue and opened a ticket with Apple. This was their response, I ultimately wound up using another solution via our CDN because it was determined our iOS developers didn't want to proceed this way, but thought it may be helpful to anyone still dealing with this issue.
''' The situation you describe, where the Cookie and other custom header information is stripped out in an AirPlay session on a Roku device from your iOS app, is likely due to a known architectural issue. More specifically, the reason for this is typically across AirPlay boundaries the receiver will stream the requested content independently of the iOS device, and for privacy reasons this doesn’t allow custom headers to be inserted into the request stream.
To workaround this behavior, you might consider an alternate scheme that makes use of AVAssetResourceLoader. For example, described below is such a scheme that you may be able to implement (or similar):
(1) When the application receives the master playlist URL from the server, it can still provide the cookies (via AVURLAssetHTTPCookiesKey), but turn the master playlist URL into a URL with a custom scheme (such as vid://content-whatever) and supply that to AVPlayer.
(2) Whenever AVPlayer needs to switch between local playback and AirPlay, it will re-request the vid:// URL from the app AVAssetResourceLoader delegate to obtain the master playlist
(3) If the session is not AirPlay (in other words if the User-Agent identifies as iOS, not as Apple TV or similar), the app provides the master playlist URL provided by the server to the AVAssetResourceLoader request as a redirect, - AVFoundation on the client device will then request the master playlist URL, supplying the AVURLAssetHTTPCookies as before
(4) If the session is AirPlay, then the app makes another call to its server to obtain a one-time https “cast” URL that, when sent from the Apple TV or similar, will cause the server to respond with the auth token cookies. The app provides the cast URL to the AVAssetResourceLoader request as a redirect - the Apple TV will then do a GET on the cast URL, which should provision its cookie store appropriately
If you decide to go this route, there is some archived sample code "AVARLDelegateDemo"(https://developer.apple.com/library/archive/samplecode/sc1791/Introduction/Intro.html#//apple_ref/doc/uid/DTS40014357) that may help you get started. This sample code depicts a couple of different use cases of AVAssetResourceLoaderDelegate (for Identity encryption use case scenarios) for HLS (HTTP Live streaming): - Redirect handler (redirection for the HTTP live streaming media files) - Fetching Encryption keys for the HTTP live streaming media (segments) - Custom play list generation (index file) for the HTTP live streaming. '''
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | benderzgreat |