Summary: | HTML5 video tag Does Not Load in Apache htaccess/htpasswd Protected Directory | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Andrew Peterson <andy> | ||||||||||||||
Component: | Media | Assignee: | Jer Noble <jer.noble> | ||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||
Severity: | Normal | CC: | ap, beidson, buildbot, commit-queue, eric.carlson, esprehn+autocc, glenn, gyuyoung.kim, japhet, jer.noble, jonlee, mmaxfield, pavelka, rniwa, stenseven, s+webkit, terry | ||||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||||
Hardware: | Mac (Intel) | ||||||||||||||||
OS: | OS X 10.6 | ||||||||||||||||
URL: | http://www.vitalnet.net/test/index.html | ||||||||||||||||
Attachments: |
|
Description
Andrew Peterson
2010-06-09 11:49:59 PDT
FWIW, I cannot reproduce this issue with Safari 4.0.5 on Mac OS X 10.5.8. I see that the platform field says 10.6, but what exact versions of Mac OS X and QuickTime do you have? I'm seeing the problem on: Mac OS X 10.6.3 (10D578) QuickTime X Latest Snow Leopard release, with these: QuickTime Player 10 QTKit 7.6.6 QuickTime 7.6.6 I can reproduce this on three computers: Mac Pro 1,1 (4 core), Mac Pro 3,1 (8 core) and a MacBook Pro 3,1. All are running the same software and OS versions (latest SL updates). *** Bug 50259 has been marked as a duplicate of this bug. *** > http://www.vitalnet.net/testprotected/index.html
This page doesn't ask for password any more. Would it be possible for you to restore the test case, or make one that could be attached here (for serving with Apache on localhost)?
Thanks for pointing out that the password protected test was broken. We moved to a new server (same type of RHES/Apache server) and apparently the password protection was not implemented after the move. I have re-enabled the password protected directory and can confirm that the bug appears to be fixed as the HTML <video> is now loading and playing properly. However, my test platforms have changed. I am now running Lion 10.7.1 with Safari Version 5.1 (7534.48.3) and I have also tested it as working on the iPad 2 (with latest iOS). We have updated all of our Macs here to Lion, so someone on Snow Leopard should test to confirm. Thanks! (In reply to comment #6) > Thanks for pointing out that the password protected test was broken. We moved to a new server (same type of RHES/Apache server) and apparently the password protection was not implemented after the move. I have re-enabled the password protected directory and can confirm that the bug appears to be fixed as the HTML <video> is now loading and playing properly. > > However, my test platforms have changed. I am now running Lion 10.7.1 with Safari Version 5.1 (7534.48.3) and I have also tested it as working on the iPad 2 (with latest iOS). We have updated all of our Macs here to Lion, so someone on Snow Leopard should test to confirm. > The AVFoundation based media engine can use credentials that are already in the system keychain, the problem is when you authenticate with Safari and do *not* tell it to save to the keychain. Can you make sure that your login credentials are not in your keychain and try again? To hopefully percolate this issue up, Safari 6.0.4 also exhibits this incorrect behavior (does not load the <video> element if it's placed within a .htaccess/.htpasswd protected directory, even after successfully authenticating). The original poster's test site above is still active and demonstrates the issue. If the "Remember this password in my keychain" is checked in the authentication dialog, video loads properly. From Eric_Carlson's comments, it appears that the credentials are then handled by the OS instead of Safari. In running the nightly WebKit build r148754, video failed to load on the above test site even when "Remember this password in my keychain" was checked. OS X 10.7.5 2.8 GHz i5 iMac (In reply to comment #8) > To hopefully percolate this issue up, Safari 6.0.4 also exhibits this incorrect behavior (does not load the <video> element if it's placed within a .htaccess/.htpasswd protected directory, even after successfully authenticating). > > The original poster's test site above is still active and demonstrates the issue. > > If the "Remember this password in my keychain" is checked in the authentication dialog, video loads properly. From Eric_Carlson's comments, it appears that the credentials are then handled by the OS instead of Safari. > Not quite, AVFoundation/QTKit load media data themselves so they need the credentials. WebKit has this information when Safari authenticates, but AVFoundation and QTKit don't have a mechanism to request them from WebKit, but they are able to read the keychain so they can get credentials when they have been saved there. Eric, thank you for the clarification on AVFoundation/QTKit. Since this issue has been present since at least Safari v5, is getting htaccess authentication from Webkit to AVFoundation/QTKit a deep problem? I hope not because Safari should be able to load HTML5 <video> from an htaccess protected directory like Chrome and FF. This is a show-stopper (pun sort of intended) for video-based web apps that require simple media protection. (In reply to comment #10) > Eric, thank you for the clarification on AVFoundation/QTKit. Since this issue has been present since at least Safari v5, is getting htaccess authentication from Webkit to AVFoundation/QTKit a deep problem? I hope not because Safari should be able to load HTML5 <video> from an htaccess protected directory like Chrome and FF. This is a show-stopper (pun sort of intended) for video-based web apps that require simple media protection. Everyone is aware that this is a serious issue, the problem is "just" a lack of API. I was having trouble with media on .htaccess protected Safari sites and discovered this: # Allow direct access to video and image files in a protected directory # Props http://stackoverflow.com/a/9078460?stw=2 <FilesMatch "\.(mp4|ogv|webm|jpg|png)$"> Satisfy any order allow,deny allow from all </FilesMatch> A fix, not a solution. Created attachment 220473 [details]
Patch
Comment on attachment 220473 [details] Patch Attachment 220473 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/5580041912057856 New failing tests: http/tests/media/video-buffered-range-contains-currentTime.html http/tests/media/video-auth.html http/tests/media/video-error-abort.html Created attachment 220477 [details]
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Comment on attachment 220473 [details] Patch Attachment 220473 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/6418627028844544 New failing tests: http/tests/media/video-buffered-range-contains-currentTime.html http/tests/media/video-auth.html http/tests/media/video-error-abort.html Created attachment 220484 [details]
Archive of layout-test-results from webkit-ews-07 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-07 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Comment on attachment 220473 [details] Patch Attachment 220473 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/5364439654072320 New failing tests: http/tests/media/video-buffered-range-contains-currentTime.html http/tests/media/video-auth.html http/tests/media/video-error-abort.html Created attachment 220486 [details]
Archive of layout-test-results from webkit-ews-02 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-02 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Created attachment 220491 [details]
Patch
Skip the tests on Mavericks & ML.
Created attachment 220495 [details]
Patch
Rebaselined.
Comment on attachment 220495 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=220495&action=review > LayoutTests/http/tests/media/resources/video-auth.php:3 > + $ua = $_SERVER["HTTP_USER_AGENT"]; Nit: this doesn't seem to be used. > LayoutTests/http/tests/media/video-auth.html:22 > + var frame = document.createElement('iframe'); > + frame.width = 0; > + frame.height = 0; > + frame.addEventListener('load', function () { This is odd, is it using the iframe 'load' event instead of setTimeout()? Comment on attachment 220495 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=220495&action=review > Source/WebCore/html/HTMLMediaElement.cpp:5588 > + if (!frame) if (!page)? Comment on attachment 220495 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=220495&action=review >> Source/WebCore/html/HTMLMediaElement.cpp:5588 >> + if (!frame) > > if (!page)? ack! !page. Committed r161455: <http://trac.webkit.org/changeset/161455> Why is this issue stated as resolved? I can still reproduce the issue with the latest WebKit nightly build 538+. Removing Mavericks-specific lines from platform/mac/TestExpecations due to no longer supporting Mavericks. Committed r193663: <http://trac.webkit.org/changeset/193663> |