Bug 40382 – HTML5 video tag Does Not Load in Apache htaccess/htpasswd Protected Directory

• Component: Media
• Status: RESOLVED FIXED

[Andrew Peterson]

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.

[Alexey Proskuryakov]

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?

[Andrew Peterson]

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).

[Alexey Proskuryakov]

<rdar://problem/8077273>

[Eric Carlson]

*** Bug 50259 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

> 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)?

[Andrew Peterson]

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!

[Eric Carlson]

(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?

[Terry]

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

[Eric Carlson]

(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.

[Terry]

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.

[Eric Carlson]

(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.

[stenseven]

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.

[Jer Noble]

Created attachment 220473 [details]
Patch

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Jer Noble]

Created attachment 220491 [details]
Patch

Skip the tests on Mavericks & ML.

[Jer Noble]

Created attachment 220495 [details]
Patch

Rebaselined.

[Eric Carlson]

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()?

[Jon Lee]

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)?

[Jer Noble]

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.

[Jer Noble]

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+.

[Myles C. Maxfield]

Removing Mavericks-specific lines from platform/mac/TestExpecations due to no longer supporting Mavericks.

[Myles C. Maxfield]

Committed r193663: <http://trac.webkit.org/changeset/193663>