On our site we allow file purchases which are time-limited. I've noticed the file_key is being regenerated after each successful file download (rendering the next attempt to download the file invalid).
The download limit settings are:

Downloads - blank
IP addresses - blank
Time - 7 days

I have tracked this down to what I think is the key being regenerated in _uc_file_log_download.

The attached patch *appears* to fix the problem.

Regards,
Chris.

CommentFileSizeAuthor
#2 uc_file_download.patch513 byteschris.p.bailey
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

TR’s picture

TR CreditAttribution: TR commented

You forgot to attach the patch ...

chris.p.bailey’s picture

chris.p.bailey CreditAttribution: chris.p.bailey commented
FileSize
uc_file_download.patch513 bytes

Sorry, didn't realise i'd missed the attachment (and I also didn't get an email when you replied)

TR’s picture

TR CreditAttribution: TR commented
Issue tags: +uc_file

Tagging

TR’s picture

TR CreditAttribution: TR commented
Status: Active » Closed (won't fix)

I'm pretty sure we don't want to do that. The token is *deliberately* regenerated after every download, so that the number of downloads can be controlled. Since in your case you only limit downloads by time not by #, stopping the regeneration will help your problem but will break downloads for what I think is the more common use case of downloading files only a limited number of times.

I think the real fix needed here - and it's one that has been discussed before - is to figure out how to refresh the download page (user/%/purchased-files) after a link is clicked. The refreshed page (whether loaded manually or automatically) will have a new link, with the new key, that can be clicked again if the customer is still allowed to download the file again.

chris.p.bailey’s picture

chris.p.bailey CreditAttribution: chris.p.bailey commented

Thanks for the reply.

I would have thought recreating tokens for each download is overkill - could you not just increment a counter after each download?

The problem is that your regenerating token approach relies on the user being able to log into their account (and also being aware that after clicking on a file down link in an email, that link will never work again).

In my particular case, we try and make the buying process as simple as possible - this means I hide all mention of the user accounts from users and communicate with them only via email.

I figure generating user accounts just to view some downloaded files is a bit of overkill for my needs - you then need to worry about permissions and user interface design for authenticated users. On my site, accounts are still generated but will be created as inactive and the user is completely unaware they have an account on the site.

For my needs I'll stick with my patch as it fits our use case.

Thanks again for your response.

Chris.