Forum Replies Created
-
Posts
-
You have a header at the top of your page that contains flash code. It has some kind of logic, so that if a browser without flash is detected; it displays the download Adobe flash button. Try looking in your theme files.
As stated above, this is going to be an ongoing battle. Every time a plugin or theme update becomes available, you will have to go through the exercise of editing out non https references.
Your site has one unsecured image:
http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif
Change it to an https reference.
I also run my site in full time SSL mode. I am always fighting plugins that contain non-secured external image references.
In the directory which contains your files, check to see if there is a “.htaccess” file. If there is one, rename or delete the file.
Also, with the “Do Not Convert” option on, if you were to copy the “resolved DL file path” shown in the debug logs to your browser’s address bar, can you access the file?
Please try the solution offered here…
https://support.tipsandtricks-hq.com/forums/topic/cant-download-file
Try this…
WP eStore -> Settings -> Addon Settings -> Download Manager Related Settings -> Automatic URL Conversion Preference -> Do Not Convert
I think, that because you “…changed the currency in between…” that is the reason for the second failure. When the final IPN came through, it no longer matched what eStore was expecting.
Because you successfully tested it with the sandbox, there is a high confidence level that real purchases will go through. However, if you expect a majority of buyers to have unverified accounts, any tweaks you make between the time of purchase and when the funds clear may cause similar failures.
PayPal does not provide secure image hosting. You either have to use SSL or a recommended “secure image hosting provider.”
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/solutions_imagehosting
My personal opinion is that it helps your business more to host the images on your own site than on [https://cheap-image-storage.com]
Besides, the monthly cost of these services is more than the yearly cost of an SSL certificate.
SSL is implemented through the use of SSL certificates. You pay for the certificate, regardless of whether or not you use it for all parts of the site or not.
When SSL is being used, all communications between the site and the user (or PayPal) are encrypted. In today’s computing environment, the overhead of doing full time encryption is minimal. Gmail is an example of full time SSL.
The only reasons I can see for not using full time SSL are:
1. You are using an el cheapo (free) hosting service that simply doesn’t have the capacity to support full time SSL.
2. You are running a mobile website. Most non smartphones (WAP enabled) have trouble doing SSL.
3. You are in a country that requires you to obtain a government license to use SSL.
You can also save on the cost of an SSL certificate by using what is called a “self signed” certificate. However, it is analogous to the business that makes up and posts its own “trust us” stickers. That, and the fact that most browsers issue warning messages when they detect self signed certificates.
This is one of those threads that I never receive update notifications on… 8(
Give me a few days and I’ll put together a SandBox narrative.
You don’t “really” need it, BUT it is “good for business” to have it. The PayPal recommendation is to protect against impersonation by sites other than yours. Customers are then “assured” that they are dealing with your site.
If you are not a large company dealing with large amounts of money, it is more of an image than a security item. But you should have SSL if you can afford it.
Okay, here is the definitive answer… at least for Apache users.
Both the “#1 Default” and “#7 cURL” download methods will work for any size file, with cURL being preferred because it uses less PHP execution time per megabyte. However, many may have noticed that after about 5 minutes or so the download is mysteriously terminated. Running a Unix style “strings” command on the terminated download usually reveals a “200 OK” or “500 Internal” error message.
The answer on Apache servers can be found in the httpd.conf file…
# Timeout: The number of seconds before receives and sends time out.
Timeout 300
Even though eStore overrides the PHP script execution timer, if any download takes more than the configured number of seconds; Apache will terminate the download script.
I suspect the same thing applies to IIS and other servers as well.
Now I can rest in peace, knowing what was happening!
P.S. It is unclear if the timeout is in “real” or “processor” seconds. Use of a dedicated server may give different results than shared or grid hosting.
Yes. If you trust that your customers will not pass the links around.
I recommend you use the following eStore feature to handle the selling of your streaming videos.
http://www.tipsandtricks-hq.com/ecommerce/using-wordpress-permalinks-as-digital-products-apr-1217
Well, after going through several hundred Google results, the best reason for why downloads are being terminated has something to do with the ModSecurity module in Apache.
Well, for those who want to know why downloads terminate in mid transfer, I was able to “catch” this at the end of an 80 MB test file that aborted at the 50 MB mark…
<html><head>
<title>200 OK</title>
</head><body>
OK
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>More information about this error may be available
in the server error log.</p>
<address>Apache Server at yoursite.com Port 443</address>
</body></html>
