Allowing Password Protected downloads

.htaccess question

[keyplyr]

I want users to be able to play/download media files from a page that resides in password protected directories, 2 levels deep:

/passprotect1/passprotect2/page.html

Intentionally, /passprotect1 users are filtered and are not allowed into /passprotect2. This works well. The users I allow into /passprotect2 do not need to LogIn again because their info is listed in .htaccess at both levels. This works well also.

But... when /passprotect2 users wish to use WindowsMediaPlayer to access sound files, via:

<a href="sound_files/file.mp3">click</a>

...the LogIn window pops up requiring them to sign-in again. This happens on each sound file. This is annoying :)

What code do I add to the .htaccess of /sound_files to stop these additional LogIn pop-ups?

[claus]

Where in the folder hierarchy is /sound_files/ placed, relative to

/passprotect1/passprotect2/page.html

?

- and do you have a <Files mp3> directive in any existing .htaccess on this site?

[keyplyr]

Where in the folder hierarchy is /sound_files/ placed, relative to
/passprotect1/passprotect2/page.html

/sound_files is in /passprotect2 the same level as the page.html

do you have a <Files mp3> directive in any existing .htaccess on this site?

No, not sure how to write it, but I'll fool around with it, thanks.

[keyplyr]

Can anyone share experience with this?

This is the log activity when I click the <a> link to play the mp3 file]. I am using WMP, but I want to add access for any audio player/pluggin:

(notice the second log entry. Windows-Media-Player does not carry the USER name. That's where I am promted to LogIn again.)

68.6.204.205 - USER [13/Oct/2003:01:45:37 -0700] "GET /Protect1/Protect2/audio_files/whisper.mp3 HTTP/1.1"
200 33884 "http://my_domain.com/Protect1/Protect2/page.html" "Mozilla/4.0
(compatible; MSIE 6.0; Windows 98; Win 9x 4.90; Q312461)"

68.6.204.205 - - [13/Oct/2003:01:45:40 -0700] "GET /Protect1/Protect2/audio_files/whisper.mp3 HTTP/1.1" 401
688 "-" "Windows-Media-Player/9.00.00.3008"

68.6.204.205 - USER [13/Oct/2003:01:45:44 -0700] "GET /Protect1/Protect2/audio_files/whisper.mp3 HTTP/1.1"
200 33884 "-" "Windows-Media-Player/9.00.00.3008"

68.6.204.205 - USER [13/Oct/2003:01:45:45 -0700] "GET /Protect1/Protect2/audio_files/whisper.mp3 
HTTP/1.1" 206 31320 "-" "Mozilla/4.0 
(compatible; MSIE 6.0; Windows 98; Win 9x 4.90; Q312461)"

[claus]

Ah you've found the problem :)

You could link to the file using the format

username:[e-mail]/path/to/file.mp3

I'm not entirely sure about the syntax, byt there is a way to do it like this.

/claus

[keyplyr]

Thanks Claus, I can certainly play around with that idea, but I was really after a more generic rule, since an inline fix would eventually add up to code bloat.

I've tried variations of:

<Files mp3> 
order deny,allow 
allow from all
</Files>

...which doesn't work. Maybe it's just Windows-Media-Player that is having the problem, since it is not a browser pluggin, but a program embedded in the OS and uses a blank referrer.

- or - is there some rule that would over-ride this password list to allow everyone that has made it to the second directory to have access to these mp3 files?

AuthUserFile /www/d/domain/.htpasswd
AuthGroupFile /dev/null
AuthName "USERS"
AuthType Basic

<Limit GET>
require user Arnold
require user ...
</Limit>

[keyplyr]

Well, making progress but still no cigar. A friend suggested using "Satisfy any"

Can anyone shead any light why this does not work? Thanks.

AuthUserFile /www/d/domain/.htpasswd 
AuthGroupFile /dev/null 
AuthName "USERS" 
AuthType Basic 

SetEnvIf User-Agent ^Windows-Media-Player/ WMP 
<Files /audio_files/*> 
Satisfy any 
Order allow,deny 
Allow from WMP 
Require valid-user 
</Files> 

<Limit GET> 
require user Arnold 
require user ... 
</Limit> 

[jdMorgan]

keyplyr,

Be aware that the <Files> directive must contain a complete filename (relative to the current .htaccess directory) or the wild-card character "*". This is not standard regular-expressions syntax. You may want to try using <FilesMatch> instead; It uses regex, and so is more flexible for matching the filename.

Jim

[keyplyr]

I've given up. 2 1/2 days of this is enough. Thanks for the help.

<added>Well, maybe a few more attempts... LOL

Should I be adding this:

SetEnvIf User-Agent ^Windows-Media-Player/ WMP
<FilesMatch /audio_files/*>
Satisfy any
Order allow,deny
Allow from WMP
Require valid-user
</FilesMatch>

to the .htaccess in each directory, or just the audio_files directory?

(/ProtectedDirectory1/ProtectedDirectory2/audio_files/)

[claus]

>> Can anyone shead any light why this does not work?

You did so yourself: "Windows-Media-Player does not carry the USER name" - so you can't inherit the username-password from the browser to the media player. The User-Agent has to tell the server that it's authorized somehow, that's why the server prompts for a password.

That's also why i suggested sending the username-password in the link. There's a security consideration though: That kind of link can be copied to a non-password-protected page.

>> FilesMatch /audio_files/*

Okay, this one is a bit subtle.

Files

and

FilesMatch

matches only filenames. Directory names will not get matched, so including a directory name makes it stop matching. If the only common thing among these filenames is the "mp3" extension, then that is what you want to put there.

<FilesMatch mp3$>

The above one says "the three last characters of the filename are mp3", so this might do the trick (i'm relying on jdMorgans comment that FilesMatch will understand the dollar sign to mean "end of string"):

--------------------------------------------------------

AuthUserFile /www/d/domain/.htpasswd 
AuthName "USERS" 
AuthType Basic 
Satisfy any 
require user Arnold 
require user ... 
 
SetEnvIf User-Agent ^Windows-Media-Player/ WMP 
 
<FilesMatch mp3$>
Order allow,deny 
Allow from WMP 
</FilesMatch> 

--------------------------------------------------------

I have rearranged the lines form your post #7 a bit. I've moved

Satisfy

out of the

Files

container, and deleted the reference to the

AuthGroupFile

that you did not use anyway. Oh, and i've ignored that the users should only be prompted when they make "GET" requests, now they will have to have username&password for ANY type of request, it's a bit safer.

What the above does (or at least what it is intended to do) is - literally - to: Prompt anyone that (a) is not "WMP" AND (b) does not ask for mp3 files, for username and password, and don't allow access unless they are on the user list.

This, of course, implies that "WMP" will never get prompted for a password, unless it's asking for something else than a file ending in mp3. So opening a deep link to a mp3 file in WMP will work.

/claus

[keyplyr]

First, thanks Claus. I may have screwed something up along the way, but when I set it up as you suggested, it let everyone in without logging in. So then I tried keeping my <limit GET> list and just added:

SetEnvIf User-Agent ^Windows-Media-Player/ WMP 
<FilesMatch mp3$> 
Order allow,deny 
Allow from WMP 
</FilesMatch> 

I had to LogIn (good), and got into the next protected area (good), but when I clicked on a link to an mp3 file, I got my 403. So I'm guessing that only the WMP is allowed access to mp3 files, but the browser has to make the request first... so I then tried:

SetEnvIf User-Agent ^Windows-Media-Player/ WMP 
<FilesMatch mp3$> 
Order allow,deny 
Allow from WMP 
[b]Allow from valid-user[/b]
</FilesMatch>

But 403 again.

I'm developing a blister on my index finger now, it's not a pretty sight!

[claus]

I must have messed up as well, sorry.

>> Allow from valid-user

This should be "Require" and not "Allow from". The

Require

directive is what makes the server look at your password file.

>> Limit

It's not good to use this, but if you have to (it seems so), put a <LimitExcept> before it, as suggested in the Apache doc:

------------------------

<LimitExcept GET>
Deny from all
<LimitExcept>
 
<Limit GET>
...
</Limit>

------------------------
[httpd.apache.org...]

This will deny anyone from using other methods than GET. Those that do use GET will have to make it through the constraints of the <Limit> directive.

There's a lot of subtle logic in these things and you have to be very strict about it. The browser (username+password) should be allowed access to the file as well as the mediaplayer, so you're probably right in your last suggestion (apart from allow/require)

/claus

[keyplyr]

Thanks Claus. No joy - still getting 403.

2 points: WMP isn't being identified correctly or else all this additional stuff would not have been necessary. Also, using this code...

SetEnvIf User-Agent ^Windows-Media-Player/ WMP 
<FilesMatch mp3$> 
Order allow,deny 
Allow from WMP 
Require valid-user 
</FilesMatch> 

...isn't allowing users somehow. I tried putting it above and below the users list.

Anyway, I haven't been able to shake the extra LogIn, but the files do play online and of course, the user can download to desktop without the extra LogIn since WMP isn't involved. Just seems mickey-mouse to me, but maybe I (we) will figure it out eventually :)

[jdMorgan]

What happened to "Satisfy any"?

I believe it will be required to make this work.

Jim

[keyplyr]

Hi Jim, well when I add "Satisfy any" it does allow the file to be played, but doesn't stop the additional LogIn - that's why I'm thinking the WMP is not being identified/allowed properly. However, I can only test from my one machine with my one browser IE6.

AuthUserFile /www/d/domain/.htpasswd
AuthGroupFile /dev/null
AuthName "USERS"
AuthType Basic

SetEnvIf User-Agent ^Windows-Media-Player/ WMP 
<FilesMatch mp3> 
Satisfy any 
Order allow,deny 
Allow from WMP 
Require valid-user 
</FilesMatch>

<added> Claus, as for the LimitExcept, it caused this error:

htaccess: Invalid command '<LimitExcept>', perhaps mis-spelled or defined by a module not included in the server configuration

[jdMorgan]

key,

<LimitExcept> is a core directive, so it cannot be "dis-included." However, it is supported only by Apache 1.3.5 and above.

As for the "big" problem, have you looked at this Apache document [httpd.apache.org]? I'd recommend taking their example, and modifying it one small step at a time toward what you want it to do.

Jim

[keyplyr]

Thanks Jim, I will give it another go once I get my second wind.

<addded> My Server is: Apache/1.3.28 (Unix)

[claus]

A real bugger this one, isn't it? It seems to me that there's something here that doesn't behave as it's supposed to do.

>> WMP isn't being identified correctly

That could be it. SetEnvIf and SetEnvIfNoCase was included in Apache version 1.3. Add this to what Jim says above and i start to suspect you're running an earlier version - could this be true?

The module is called "mod_setenvif" - perhaps your host can tell if you have support for it?

>> post #11,13: isn't allowing users somehow

"Require valid-user" - you did write a valid username in stead of "valid-user" i hope? If not, that's why no users have access.

>> "Satisfy any" it does allow the file to be played, but doesn't stop the additional LogIn

The "Satisfy any" is required when you use both "Allow" and "Require" - without it the server assumes that both conditions must be met (ie. both username-pw and WMP). For this reason it should be "any", so that you don't need to enter password if you have the WMP.

It does indeed seem like WMP is not being recognized, as what you describe would be "Satisfy all" (the default).

>> above example
Before you try the <Directory> from the above example - this does not work in a .htaccess context, only <Files> does.

Otherwise, i would put the "Require" line before/above the "Order" line (as the above example also does), but perhaps that's just an insignificant detail.

Apart from all this, i don't really have a clue, i'm sorry to say. This darn thing simply ought to work like we told it to, but as usual the server fails to read our minds it seems. How does your .htaccess file look now - was post #15 the whole thing (the access-related part, that is)?

/claus

---

Thats it!

Just saw your above post keyplyr, this quote is from the documentation of SetEnvIF

Module: mod_setenvif
Compatibility: Apache 1.3 and above; the Request_Protocol keyword and environment-variable matching are only available with 1.3.7 and later; use in .htaccess files only supported with 1.3.13 and later
-link: [httpd.apache.org...]

-bold added. Is a server upgrade possible?

[keyplyr]

>>Is a server upgrade possible?

Nope

<added> I have used SetEnvIf before with no problems

I have the following modules installed:
http_core.c
mod_env.c
mod_define.c
mod_log_config.c
mod_mime.c
mod_negotiation.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_asis.c
mod_actions.c
mod_speling.c
mod_alias.c
mod_rewrite.c
mod_access.c
mod_auth.c
mod_auth_dbm.c
mod_expires.c
mod_unique_id.c
mod_setenvif.c
mod_ssl.c
mod_cgiwrap.c
mod_phpcgiwrap.c
mod_frontpage.c
mod_dosevasive.c
suexec: enabled; valid wrapper

[jdMorgan]

key,

> Request_Protocol keyword and environment-variable matching are only available with 1.3.7\

That is to say that SetEnvIf can only access the %{REQUEST_PROTOCOL} variable, and can only match other non-http-request-related environment variables (see the last line of the example under SetEnvIf) in Apache 1.3.7 or later. The module itself is available in 1.3 and later, and support for mod_setenvif use in .htaccess was added at rev 1.3.13.

So Apache 1.3.28 covers all except matching REQUEST_PROTOCOL and the "proprietary-variable" matching as shown in the cited example, neither of which are used in the present application.

Well, I hope you get your second wind. When you get frustrated, let it go. You WILL get it working, but probably when you're fresh, not when you're frustrated or angry.... :)

It looks like all the critical modules are present and accounted for on your server.

Best,
Jim