Here is the download page. The documents are set as protected. An email is sent to the email address entered on the form. However the link back to download the form gives the message that the anonymous user does not have access to the file for download.

Access download here: http://www.rea-corp.com/drupal/original

CommentFileSizeAuthor
pd_protect.jpg78.68 KBemerygjr
pd_submit.jpg57.56 KBemerygjr
pd_form.jpg38.33 KBemerygjr

Comments

berliner’s picture

berliner commented
Status: Active » Postponed (maintainer needs more info)

Please make sure that the private_upload module is configured correctly. I can access the protected file using the url to the default file directory: http://www.rea-corp.com/drupal/sites/default/files/private/Architecting%...

Do you have any other node access modules installed that might interfere with the access control of the given files?

pirmin’s picture

pirmin commented

Also, make sure the (webform) page itself has been published.

When logged in, I'm able to go through the entire process even though the webform page itself hasn't been published. I'm obviously the owner of the (webform) page in question.

When the page hasn't been published, anonymous users will get the body from the Protected Downloads (Thank you for interest...) however won't be able to actually download the file unless the respective (webform) page has been published.

It's a bit counter-intuitive when one encounters this because one would expect the page with the hash (for which the url shares the same prefix as the otherwise unpublished webform url) to already generate some kind of Access Denied error.

When [webform_id] hasn't been published:
* http://www.example.com/node/[webform_id]/download/[hash] is available for everyone
* http://www.example.com/system/files/private/attachment is available for the owner of [webform_id] however produces Access Denied for anonymous.

Although the process works fine for published pages, it would be more consistent if the access denied is already generated when anonymous accesses http://www.example.com/node/[webform_id]/download/[hash] whenever [webform_id] hasn't been published since one would expect the permissions of the body of Protected Downloads to be governed by the permissions of http://www.example.com/node/[webform_id]

berliner’s picture

berliner commented

Good point on the access denied for unpublished webforms! I completely agree on that and changed the code to make it that way. Just committed it.

pirmin’s picture

pirmin commented

Thanks for the quick commit berliner. I bumped into the situation in the middle of last night. It's such a corner case that really won't manifest itself when the form is published but does arise when testing the unpublished form. I'm logged in editing the (unpublished) webform using Firefox, receiving the download email and then trying the link using an anonymous session from Chrome wherein the situation manifests itself.

It took me a couple of minutes to conjecture what was going on which is considerably less time (several hours) to realize that safe_mode doesn't interact nicely with private uploads. I hope this information can be of help for others.

Thanks for the protected download module. It seems to be functioning just fine over here.

emerygjr’s picture

emerygjr commented

The link to the document from the download page is:

http://www.rea-corp.com/system/files/private/Energy%20Procurement%20Risk...

which gives access denied.

If the link is changed to:
http://www.rea-corp.com/sites/default/files/private/Energy%20Procurement...

Where /system/ is replaced with /sites/default/

You can test from: http://www.rea-corp.com/original

berliner’s picture

berliner commented

The document should not be accessible using the direct path (sites/default/files/private) so it seems to me, that you didn't follow all the necessary install steps from the private_upload module. Please try to correct this and see if the problem still persists.

Anonymous’s picture

Anonymous (not verified) commented
Version: 6.x-1.x-dev » 6.x-1.0-rc3

Same issue here.
I don't say this is a bug, I am just following this thread. This module can solve a lot of problems for me if I can get it going, it's a great idea.

I created a webform, attached a file (a small jpg), checked it as protected, published the webform.

The link is emailed to me, and I can access the download page as anonymous, but when I try to download, I get this:
you do not have permission to access the requested resource

An authorized user *can* download the file.
Anonymous user has permission to access node content, and that's all. Does anonymous need some other permission?

- - -

BTW when I attach the file I do get a few strange messages like:

warning: Parameter 2 to webform_protected_downloads_form_alter() expected to be a reference, value given in /Library/WebServer/Documents/mysite/includes/common.inc on line 2892.
and
warning: Parameter 1 to theme_private_upload_form() expected to be a reference, value given in /Library/WebServer/Documents/mysite/includes/theme.inc on line 656.

I don't know if those messages are relevant.

The attachment uploads to the right place (files/private).
-rw-rw-r-- 1 _www _www littlefile.jpg

berliner’s picture

berliner commented

The anonymous user also needs the "view uploaded files" permission.
No idea for the warnings though. What version of drupal is this?

Anonymous’s picture

Anonymous (not verified) commented

OK that fixed it, thank you so much for that quick reply!

[It's Drupal 6.20. I just ignored those messages and kept going. If it happens again I guess I should start a separate thread.
Meanwhile I will try a bigger form and bigger attachment.]

mfb’s picture

mfb
they or he
commented

Please try the patch on this issue: #1179064: Cached access denied page at system/files/private/... (making sure to clear your cache). I wasn't sure this bug was the same as no one mentioned caching, but maybe so as the page cache is only for anonymous users.

berliner’s picture

berliner commented
Status: Postponed (maintainer needs more info) » Fixed

closing this old issue

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.