.htaccess for sites with a non-root base path

I'm not exactly sure what you're trying to do, but the proposed absolute path definition in .htaccess shouldn't be necessary.

Yes, it is necessary.

If you install drupal in the root directory, then the existing code works fine.

If you install drupal in a sub-directory (e.g., just untar the drupal distribution into your http root, so that you will then access it through, say, http://localhost/drupal-6.19/), then the current .htaccess doesn't work; it needs to be

RewriteBase /drupal-6.19/system/files/private

If you use the base_path() as suggested, then for the installation where drupal is in the root directory, base_path returns "/" and it works as before. Otherwise, base_path() returns "drupal-6.19/", and then the .htaccess is still created correctly.

Sorry, but I am unable to reproduce this issue. As a matter of fact, the module was created (and originally tested) from a sub-directory.

Just to be sure, I proceeded to test it (again) using a fresh install of Drupal in a sub-directory and enabled Private Download.

My files directory is located in sites/default/files and I used the default Private Download settings.

I manually uploaded a file to the private directory (sites/default/files/private).

I created a user and give the "authenticated user" role "access private download directory" permission.

I logged out and attempted to browse to my file (exp. http://www.example.com/drupal/system/files/private/image.jpg) and correctly see "Access Denied".

I then log in with my newly created user and again browse to my file (same URL) and the file is fully accessible.

If you provide more details I am happy to explore the issue further.

Did you actually test http://www.example.com/drupal/system/files/private/image.jpg? Because that is the already-rewritten URL. You meant, of course, to test http://www.example.com/drupal/sites/default/files/private/image.jpg.

I have followed exactly the steps you outline, and when I access http://www.example.com/drupal/sites/default/files/private/image.jpg after logging out, the image is returned (but if I access through system/files/... I do see access denied). Assuming that you have tested correctly, then the only thing I can think is that my apache is rewriting differently than yours -- I have tested Apache 2.0.68 on MacOS X and 2.2.3 on Windows Vista. Drupal isn't really involved with the rewriting, but for the record I am testing 6-19.

Actually, you're right. In my haste I tested the rewrite path, which obviously works.

OK, let's try this again. By adding the sub-directory to the .htaccess RewriteBase path (exp. RewriteBase /drupal/system/files/private) on the Private Download settings page (admin/settings/private_download) the above example URL works as expected.

I'm sorry for prolonging this thread for something so simple. Bottom line, I believe this is a documentation issue and adding base_path() to the bath in the code is completely unnecessary. Nevertheless, I thank you and beatnbite for raising awareness.

I've read through this conversation and picked up enough tips that I can finally configure the module settings without getting an error, and it finally wrote the htaccess file in my private directory. Yeah! Thanks!

But now I can't figure out how to link to my private files. When I link to:
http://mydomain.com/drupal/sites/default/files/private/test.pdf
It nicely redirects to:
http://mydomain.com/drupal/system/files/private/test.pdf

But I get a 500 Internal Server Error.

My drupal install is in mydomain.com/drupal.
My private directory is located in sites/default/files/
The htaccess file in that directory (created by the module) contains:

RewriteEngine on
RewriteBase /drupal/system/files/private
RewriteRule ^(.*)$ $1 [L,R=301]

So, what am I missing? Can anyone help? I don't know what information you need beyond this.

Your config appears to be correct. Since the redirect is working as expected the 500 error suggests the problem is lower level... meaning something's wrong with your web server config. I can't think of what the problem could be off-hand. Perhaps someone else can jump in w/ some suggestions otherwise GIYF.

Please report back here once you have the issue resolved so others will benefit.

Thanks,
John

Yes, it is true that when the site is configured, the admin can go alter the default .htaccess path if necessary in order to get the module to function correctly.

But I don't understand why you are against simply creating the default .htaccess path correctly in the first place? Why cause more pain for users of your module, when it could work out of the box, correctly, for users regardless of where drupal is installed?

Is there any chance that it could be caused by the fact that I briefly changed the drupal file system to private, and then changed my mind? From what I've read, the "warning" on the file structure page is a bit understated, and that messes up a lot of things.

I'm assuming that this is the problem, so I'm going to restore from my latest backup and go from there. Thanks.

@klflote,

The truth is this issue impacts an extremely small percentage of users of the module, as most run their application from the webroot. The default settings are just that, default, and may require tweaking to suit one's particular server configuration. Since we have thoroughly documented a viable solution here this is not a high priority for me.

That said, I'm perfectly willing to make the modification when time permits (along with another low priority open issue.)

Thanks again for your interest and contribution.

John

I just rolled this fix into version 6.x-1.2. Thanks again for the bringing it to my attention.

I'm still getting the internal server error. Here's what I've tried:
1. restoring from a backup before I tried switching to a private file system.
2. upgrading to private_download 6.x-1.2
3. uninstalling, deleting the module and private directory, and reinstalling
4. disabling the content_access model to make sure it wasn't conflicting

And I'm still getting the same 500 Internal Server Error. I'm getting the same error in both of the ways I'm trying to link to the uploaded file. I'm trying both ways because I'm not sure which is correct. But the result is the same either way.
/drupal/system/files/private/filename.pdf
/drupal/system/files/filename.pdf

Interestingly, when I tested the links before I re-uploaded the files, on the first link, I got a normal drupal "Page Not Found" error. But with the second link format, even without the file being uploaded, I was getting that Internal Server Error.

The only other variable I can figure may be affecting my results is the fact that I had tried the private_upload module first. But I have deleted that module now. (it didn't provide an uninstall option)

Is there anything else I should be checking?

@pltmdude,

Do me a favor and create a new issue since your problem is unrelated to the original issue of this thread. That way the title will accurately reflect the problem and you're likely to get a better response.

Thanks,
John

I was struggling with the general "Page Not Found" problem that appeared as several issues in this module (at least 3 issues were opened with the related "page not found" pathology). I think symthoms can get pretty soon mixed up with miss configured servers, and cache issues, whether local browser or server cache.
Having said that, I will say what was my particular problem and solution.

I downloaded the module, enabled on a D6 with some decent amount of modules installed (not a vanilla site with just CCK). I followed Kyle's walk through ( http://drupal.org/node/967160 ), obviating the step of creating a CCK field for uploading files, as I have one already. I was getting the missleading "Page Not Found", and none of the posted problems seemed to work for me. Then I ran into this thread, which talks about the relative path to a non-webroot, and dared to look at my URL.

I noticed that my URL to access the file as anonymous was
$UrlBase/$sitename/sites/default/files/private/filename.txt

which is wrong, as I only need
$UrlBase/sites/default/files/private/filename.txt

But the module being patched as explained here left me thinking. I went back to the configuration, and saw the problem: My default ".htaccess" snippet had a misconfiguration as my RewriteBase
was :

RewriteBase $sitename/system/files/private

changed to
RewriteBase /system/files/private

and all went fine.

Perhaps it is still all fine, the module works as intended, and users should pay attention to the default rule offered -- noted -- however, some of us are going to follow some Readmes/documentation that are not going to capture notable apache configurations (not to mention other servers) that may get on the way of the user (causing some frustration). I would add to Kyle (kbk's) description a cautionary note at step 3), to ask the user to really read the rewrite rule offered as "default".

That is all, thanks for the module john (Bacteria Man)
- inigo

Perhaps I should add a clarification to the earlier post (#16) --

in my case, I have a multiple sites handled by Apache -- Apache routes requests for URL Bases to "folders" that are then picked up by this module and offered as default in the RewriteBase rule as
RewriteBase [subdirectory/folder]/system/files/private

Which would be OK, but in my case is not, as the webroot for this instance is not the system default (like
/var/www ) in Ubuntu, but whatever folder is placed on according to my "available sites" configuration. I reiterate this is outside the scope of the module, as any user should read the default rules offered in the config, and make sure those apply, but at least a warning about it.

cheers, inigo