[Webkit-unassigned] [Bug 178551] PLaying HLS on HTML5 doesn't respect cookies from another domain

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 20 11:55:36 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=178551

--- Comment #4 from Jer Noble <jer.noble at apple.com> ---
(In reply to ealarcon from comment #3)
> (In reply to Jer Noble from comment #2)
> > (In reply to ealarcon from comment #0)
> > > The new third party policy of cookies, blocks all cookies from a third party
> > > media server, making it impossible to track the state of the player.
> > > 
> > > The RFC specifically states:
> > > 
> > >    HTTP requests often include session state ("cookies"), which may
> > >    contain private user data.  Implementations MUST follow cookie
> > >    restriction and expiry rules specified by "HTTP State Management
> > >    Mechanism" [RFC6265] to protect themselves from attack.  See also the
> > >    Security Considerations section of that document, and "Use of HTTP
> > >    State Management" [RFC2964].
> > > 
> > > Besides still not supporting MSE.
> > 
> > Can you provide a test case?  And is this behavior any different for image
> > resources?
> 
> Hello, i've created a demo for testing:
> 
> http://www.altavoz.net/hls_test/
> 
> If you try it, the player will play for about 15 seconds before coming to a
> stop, this is because the state cookies that the media server sets up for
> the player are ignored and not returned, so the media server doesn't know if
> the player is working.
> The media server is in another domain, so i expected the cookies to be kept
> only for the playing session, and then erased.
> I've made the test of visiting de media server "home" and then going back to
> the site with the embedded media, and it plays fine but makes it impossible
> to use the media content on multiples sites and have a central media server.

Are you looking for the cookies on the request for the .m3u8, or for the requests on each of the .ts segments?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171020/2f1e4778/attachment.html>


More information about the webkit-unassigned mailing list