Download Redirect 403 Forbidden Server Error

[Jay Gee]

After returning via login to collect a download by redirect for a "paid by check" order which was set to "processing" in ADMIN> Orders>I was presented with an order recapand download button displaying the number of downloads I am allowed.

After clicking on Download, a 403 Forbidden Error was thrown explaining:

"You don't have permission to access /Zencart/pub/.redirect-session-folder-name/downloadfilename.pdf

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."

-----

I am running v 1.3.8a on a Unix server with the following permission settings:

for Zencart/pub/ 777 (universal everything);

for Zencart/ 755;

for the generated /.redirectsesionfoldername/ 777;

and,

for the downloadfilename.pdf 444 (universal read-only).

A previous test was run with a /Zencart/pub/ folder permission setting of 755 and it produced the exact same result.

Server particulars are:

Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8.i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at mydomain.com Port 80

I see froma search of the forums that this is a recurring problem.

Admin setting is to redirect download.

File is recognized in attributes and product.

I have two questions:

1.) Is the download number allowed in the attribute settings the allowed number of download attempts, or the number of complete downloads allowed?

2.) Does anyone see a problem with the settings or server information above which would cause the server to keep throwing a Forbidden Error when everything is in its proper place?

Thanks for your help.

[DrByte]

a 403 Forbidden Error was thrown explaining:

"You don't have permission to access /Zencart/pub/.redirect-session-folder-name/downloadfilename.pdf

A 403 error means that rules in the webserver software (not Zen Cart) prohibited you from doing what you were attempting.
The exact reason for the prohibition will be documented in the server's errorlog (ie: apache errorlog), usually accessible from your hosting company's control panel.

1.) Is the download number allowed in the attribute settings the allowed number of download attempts, or the number of complete downloads allowed?

The number is the number of allowed download attempts, and is completely unrelated to the 403 error, since the 403 error is NOT generated by Zen Cart.

2.) Does anyone see a problem with the settings or server information above which would cause the server to keep throwing a Forbidden Error when everything is in its proper place?

A 403 error for a .pdf document type sounds like you've got some sort of prohibition for .pdf files, probably in the .htaccess file of either your /pub/ folder or your /ZenCart/ folder, or the root folder above that.
Again, the real cause will be documented in the apache logs. If you can't find those logs, you'll need to contact your hosting company.

[Jay Gee]

A 403 error means that rules in the webserver software (not Zen Cart) prohibited you from doing what you were attempting.
<snip>

The number is the number of allowed download attempts, and is completely unrelated to the 403 error, since the 403 error is NOT generated by Zen Cart.

As a result, if the attribute setting allows 4 download attempts and the customer is successful at downloading on the first attempt, the order in the cart will show complete if the customer were to check it... correct?

Thanks for your help!

[DrByte]

No, the act of downloading a file does not change the order's status in your admin area.
You have to update your order status yourself. That is not automated.

[Jay Gee]

No, the act of downloading a file does not change the order's status in your admin area.
You have to update your order status yourself. That is not automated.

Does a successful download attempt by the customer on the first try foreclose the customer's ability to return for another download of the same file if the number of allowed download attempts defined in the Attribute Settings is greater than ONE?

Put another way, if the Attributes settings allow 4 downloads (even though the language used in the Admin pages indicates "downloads" not "download attempts"), are you really giving the customer the ability to download a file successfully four times if s/he were to try four times via Login and Profile>My Orders lookup?

I realize that the if the Session used a credit card purchase that provided good funds, the transaction would be completable at the time of purchase and the Session would go away, I presume it would provide a completed order in the Admin files, not an Open Order. Is this also correct?

Thanks for illuminating.

[DrByte]

The attribute setting of "4 downloads" means the customer is allowed 4 download attempts, whether during their login session when they purchased, or by returning to their My Account order history at a later date, prior to the date of expiry which you may have also set as part of the attribute settings.
And, yes, that means they *could* download successfully 4 times. Or, they could even start but fail to complete the download 4 times.
After 4 attempts, their download link will be expired. To reset it for them, you can click the reset option in that order's details in your admin area.


Again, none of this is related to solving a "403 forbidden" problem which you reported as your initial problem.

[Jay Gee]

No, the act of downloading a file does not change the order's status in your admin area.
You have to update your order status yourself. That is not automated.

The attribute setting of "4 downloads" means the customer is allowed 4 download attempts, whether during their login session when they purchased, or by returning to their My Account order history at a later date, prior to the date of expiry which you may have also set as part of the attribute settings.
And, yes, that means they *could* download successfully 4 times. Or, they could even start but fail to complete the download 4 times.
After 4 attempts, their download link will be expired. To reset it for them, you can click the reset option in that order's details in your admin area.


Again, none of this is related to solving a "403 forbidden" problem which you reported as your initial problem.

The 403 Error solution will will have to come from another direction.

I was interested in learning what the ZenCart's default behavior is and the thread had already led in that direction.

If as a retailer you are selling items which have value, are secured and not copyable, you are not interested in giving away multiple copies when someone buys only one. It appears that the default programming of Zencart might allow additional copies to be given away from the description of the Atrribute characteristics you have given me.

Thanks for your help and the information.

[DrByte]

It appears that the default programming of Zencart might allow additional copies to be given away from the description of the Atrribute characteristics you have given me.

Well, it's not the "default programming", but rather the default settings.
You can of course reduce the number of allowed download attempts when you set up your products, to suit your specific needs.

[Jay Gee]

Well, it's not the "default programming", but rather the default settings.
You can of course reduce the number of allowed download attempts when you set up your products, to suit your specific needs.

Dr. B.

You seem to be on top of what ZenCart offers in terms of functionality.

No disparagement or offense intended, but if the script programming does not detect a successful download event on the part of the customer and thereafter cut off future downloads of the same file by the same customer without going through another complete purchase cycle, the default programming of ZenCart allows "n" downloads of the same bought file if the Attribute setting for Downloads is "n."

If I set downloads to 1 and the cutomer experiences a connection interrupt and download failure for whatever reason (not a 403 error), and then returns to download the file, the customer file will show no downloads, as if the order was completed. The ZenCart script will have concluded that the file was downloaded even though the download was not successful. If I set downloads to 2, the customer gets 2 tries with no guaranty of success.

Do you see what I am getting at?

Am I correctly stating what happens in the ZenCart environment as it is currently programmed?

[DrByte]

I see exactly what you're getting at. And that's the nature of serving files from a webserver: you DO NOT ever know for sure whether the customer's download completed exactly, unless you ask THEM to tell you ... and ... Zen Cart doesn't ask the customer to confirm whether the download completed to their satisfaction. Instead, it lets them download again (to the max which *you* the shopowner have set) if they need a retry.

If you have a better method that's 100% reliable on all webservers around the world and works with 100% of the computers people use to access those webservers, please feel free to share the technical details.