The links sent via email are one-time-use-only links. But it should work at the first click, as long as you have the "Download file" permissions set to allow Anonymous users.

Glad I can help.

Your setup, assuming you've got the permissions configured right, should allow for anonymous downloads. (I've tested this on mine and it seems to work..) Are you running the latest version? I thought you said you were. I can't test at the moment but I can run a quick check tomorrow morning. It might be an issue with the module, but I'm kind of doubting that right now.

I think keeping users logged in is the best way to go anyways, but if you really need anonymous users and it isn't working, let me know and I'll attempt to track it down. (If I can reproduce the issue, which I might not be able to).

Sorry this is vague - that's what happens when I can't really see the same issue that's being presented, at least, I haven't experienced it thus far!

Yeah I'm .. pretty sure thats for admin types. I will double check.

Just so I'm clear, the email links only work for you if you're also logged into the site? Have you tried them without logging in first? In the past I have successfully downloaded the one-time links from the email, and then after that one use they expire. Is this what you are experiencing? I think your issue is separate though, from the sounds of it. Like I said I'll try to double check.. meanwhile if any of the Uberguys have thoughts feel free to post 'em here.

Right, the links will work only if I'm logged in as the user who ordered the download - if not logged in it generates the error message.

The files, once they go to completed status(i'm working this issue too with a W-ng config), are easy enough to get to.
My workaround for this will be to autogenerate the file downloads email but omit the [file-downloads] token from the body of the email and instead have the user login to download the file. Simple enough but I still want to have all the functionality in place b4 I go live.

Ever figure this out? I'm having the same issue!

It seems to only be an issue on IE...Firefox works like a charm.

Just so we're on the same page - you are able to download the files via:

Firefox - My Files area
Firefox - Linked from email

but NOT

MSIE - My Files area, or
MSIE - Linked from email

Is that correct? The function to send the file data to isn't anything special. What version of IE are you using? Are you clicking on the file, or right-clicking and choosing "Select Target As"? (That was the one time it hiccuped for me, but after that, right-clicking works ok.)

NOTE: I did see this issue occur once in Internet Explorer 6. But I can't reproduce it. If you can reproduce it every time, please let me know what steps exactly you are using to duplicate the problem so I can look at it

Well from that it looks like it's just missing the protocol... can you view the source of your email? I'm fairly certain the file downloads mail function automatically, using the l() function add the http:// protocols to all of the links it generates.

I'll test a bit on my end and see if I can come up with anything...

One other thing...I just tried copying the link from the File Download user table when I'm logged in and pasting it into the address bar of my browser....same failure. Whereas if I click on the EXACT same link it works. It seems to be something about how IE handles the address when entered in the address bar. Just thinking out loud.

Artis

BTW I'm using Ubercart RC5 and Drupal 5.7

I have permissions set for Anonymous to download. I also don't send out user information and users that are created automatically are blocked. I'd rather users not even be created in the first place but that's not possible with Ubercart at the time.

Both http:// and https:// give the same error. The error only occurs the first time because the link expires after that. That's why you get "this is not a valid download link" after the first try. I'll send you a new link and you can try it without ssl to see. The email shows https:// because I have the checkout pages secure so that's the drupalbase url when the email link is generated. I was getting the error with SecurePages turned off so it isn't the problem.

Artis

The files are the same...it has to do with how the url is parsed maybe?

The My Files and the email urls are the same...when you click on either of them the "HASH" part (after last '/') is regernerated and entered in uc_file table and the access is incremented by one. That way the email link only works once and only if it is clicked BEFORE the My Files link is clicked. Otherwise the HASH will change and the email url won't work even though it hasn't been clicked.

Now back to the issue... I think it has to do with how the uc_file module parses the url and generates the fopen and header information. I think when clicked from My Files (function uc_file_user_downloads) there is relative link href "/download/8/j3fjopa9fjp..." where as the full "http://www.sitename.com/download/8/feoau93fa" is in the address bar from the email link. Does drupal handle these differently?

Nah, the only thing the JS does is increment the access log (and makes your "Downloaded" number increase by 1).

I've done some testing but it's not really an easily duplicated problem for me. I don't believe the URLs get parsed any differently depending on the browser. My guess is something to do with the link itself... but I could be wrong. I'm still trying to figure out why the temporary link would get that kind of status... there must be something that gets checked, or passed, that lets the system know that you are downloading via an external link vs. downloading from the files list.

I don't have much time to look into it now but I will soon as I can.

It has to do with having SSL on the server. IE can't save the file with:

in the http headers. Something about needing a local cache version to pass to the download manager or file reader (i.e. Adobe Reader). See: http://support.microsoft.com/kb/316431

So changing those lines to:

works perfectly. Those lines are in function "_file_download_transfer" around line 1080 or something (I've hacked this file so much I don't know the exact number.

I know this isn't ideal for protecting the files but it works. Maybe some sort of test for SSL could be written in and then the corresponding headers could be passed?

Thanks for the help, torgosPizza!

Artis

I'm a little ignorant of all that's gone on in this thread, but I definitely want to applaud your efforts in the troubleshooting here. You guys are excellent. I'm just curious if there's anything we need to do to the module to avoid this problem in the future for other users.

All of that sounds good and is mostly over my head!

I don't know if it's easy or possible to detect if the server has an SSL cert installed. If so... use one set of headers...if not...use other set.

Or like torgos said.. make the headers a config option and the site admin can choose "SSL headers" or "Protected headers"

Artis

Hi there, I was just wondering if there is any follow up to this issue. I'm seeing the exact same problem as AEWilliams on IE7 (but not on Firefox). Can we expect the fix to be in an upcoming release? If not, can someone post the exact fix with line numbers and such?

As a side observation about anonymous downloads, reading through a lot of the forum postings over the last week, I've noticed that the feature was not designed for one-shot buyers in mind. (Yes, I'm making some gross generalizations here so bear with me.) For example, the most typical use case for my site would be a user buys one product, gets an email with the link, downloads the files and that's it. I don't really need or want that user to have an account on my site, although I am giving them the option. With that in mind, I've found that getting to this point in terms of configuration has been challenging. I'm not complaining though, and I am grateful for all the effort that people have put into making UC great. I realize that it's hard to predict how people will use a feature and I'm glad that we have this forum to hash things out and share our experiences.

torgosPizza just posted a patch for 1.4 that I want to try and get into core. cha0s tested it and it worked fine. I'd love to get some more feedback so I can feel confident committing it.

Check it out here - http://www.ubercart.org/issue/4846/making_uc_file_file_downloads_support...

I don't have any problem waiting.

Like I said, cha0s was able to patch and get it running, so code cleanup would be icing on the cake! It looks like one thing is the use of tabs instead of the two spaces, but my IDE strips those out when I save anyways.

If you can post the file here as an attachment, I'd be happy to patch my test system and give it a try. Thanks.

Just wanted to give a follow-up on this issue:

Using the latest UC 5.x-1.5 the download email works for anonymous users on IE7, Firefox 3, and Chrome. Yay!