Bug 40382 - HTML5 video tag Does Not Load in Apache htaccess/htpasswd Protected Directory
Summary: HTML5 video tag Does Not Load in Apache htaccess/htpasswd Protected Directory
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media Elements (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh Intel OS X 10.6
: P2 Normal
Assignee: Jer Noble
URL: http://www.vitalnet.net/test/index.html
Keywords: InRadar
: 50259 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-06-09 11:49 PDT by Andrew Peterson
Modified: 2015-12-07 16:09 PST (History)
17 users (show)

See Also:


Attachments
Patch (16.53 KB, patch)
2014-01-06 17:09 PST, Jer Noble
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2 (579.28 KB, application/zip)
2014-01-06 17:52 PST, Build Bot
no flags Details
Archive of layout-test-results from webkit-ews-07 for mac-mountainlion (528.85 KB, application/zip)
2014-01-06 19:59 PST, Build Bot
no flags Details
Archive of layout-test-results from webkit-ews-02 for mac-mountainlion (526.62 KB, application/zip)
2014-01-06 20:53 PST, Build Bot
no flags Details
Patch (17.25 KB, patch)
2014-01-06 22:05 PST, Jer Noble
no flags Details | Formatted Diff | Diff
Patch (17.32 KB, patch)
2014-01-06 22:46 PST, Jer Noble
eric.carlson: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Peterson 2010-06-09 11:49:59 PDT
The HTML5 <video> element does not load the video if it is placed within an Apache htaccess/htpasswd protected directory even after correctly authenticated login. I have set up two simple pages demonstrating the problem:

The files in a public directory with video that works:

http://www.vitalnet.net/test/index.html

The files in a protected directory where the video stops at 'Loading...':

http://www.vitalnet.net/testprotected/index.html

Login with: username: test | password: safari

Note that Safari 4 and 5 both load the video from the protected area and play it (without the HTML5 controls, appears with QuickTime controls) using a plain link to the file (provided at the bottom of the test pages).

This problem does not occur on iPad or iPhone. Not tested on others.
Comment 1 Alexey Proskuryakov 2010-06-09 15:21:27 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?
Comment 2 Andrew Peterson 2010-06-09 15:34:25 PDT
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).
Comment 3 Alexey Proskuryakov 2010-06-09 15:39:37 PDT
<rdar://problem/8077273>
Comment 4 Eric Carlson 2010-11-30 15:54:42 PST
*** Bug 50259 has been marked as a duplicate of this bug. ***
Comment 5 Alexey Proskuryakov 2011-09-14 14:12:05 PDT
> 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)?
Comment 6 Andrew Peterson 2011-09-15 16:27:22 PDT
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!
Comment 7 Eric Carlson 2011-09-15 22:00:30 PDT
(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?
Comment 8 Terry 2013-04-19 12:44:02 PDT
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
Comment 9 Eric Carlson 2013-04-19 16:19:57 PDT
(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.
Comment 10 Terry 2013-04-22 09:52:44 PDT
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.
Comment 11 Eric Carlson 2013-04-22 10:06:35 PDT
(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.
Comment 12 stenseven 2013-12-15 17:36:49 PST
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.
Comment 13 Jer Noble 2014-01-06 17:09:48 PST
Created attachment 220473 [details]
Patch
Comment 14 Build Bot 2014-01-06 17:52:54 PST
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
Comment 15 Build Bot 2014-01-06 17:52:57 PST
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 16 Build Bot 2014-01-06 19:59:17 PST
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
Comment 17 Build Bot 2014-01-06 19:59:20 PST
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 18 Build Bot 2014-01-06 20:53:28 PST
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
Comment 19 Build Bot 2014-01-06 20:53:32 PST
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
Comment 20 Jer Noble 2014-01-06 22:05:08 PST
Created attachment 220491 [details]
Patch

Skip the tests on Mavericks & ML.
Comment 21 Jer Noble 2014-01-06 22:46:43 PST
Created attachment 220495 [details]
Patch

Rebaselined.
Comment 22 Eric Carlson 2014-01-07 12:05:12 PST
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 23 Jon Lee 2014-01-07 12:34:33 PST
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 24 Jer Noble 2014-01-07 12:46:25 PST
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.
Comment 25 Jer Noble 2014-01-07 14:21:04 PST
Committed r161455: <http://trac.webkit.org/changeset/161455>
Comment 26 pavelka 2014-02-10 03:57:58 PST
Why is this issue stated as resolved?
I can still reproduce the issue with the latest WebKit nightly build 538+.
Comment 27 Myles C. Maxfield 2015-12-07 16:02:58 PST
Removing Mavericks-specific lines from platform/mac/TestExpecations due to no longer supporting Mavericks.
Comment 28 Myles C. Maxfield 2015-12-07 16:09:43 PST
Committed r193663: <http://trac.webkit.org/changeset/193663>